Prioritatea thread-urilor
Există o șansă ca aici să fiu învățat mai devreme decât în alte locuri :)
Lucrez sub Linux și trebuie să schimb prioritatea firului, încerc să fac asta după cum urmează:
#include
#include
static void * my_thread (void * arg)
somn (1);
>
int principal (void)
pthread_t thread;
int prioritate;
int politică;
struct sched_param param;
int res;
pthread_create (thread, NULL, my_thread, NULL);
res = pthread_getschedparam (fir, Politica, param);
prioritate = param.sched_priority;
printf ("res =. # xA0; policy =. # xA0; prioritate =. \ n ", res, politică, prioritate);
param.sched_priority = 2;
politică = SCHED_OTHER;
res = pthread_setschedparam (thread, politică, param);
printf ("res =. \ n", res);
Ca urmare, obțin:
res = 0 politică = 0 prioritate = 0
res = 22
Codul 22 înseamnă ceva de genul "parametru nevalid". Ce fac greșit?
Merită să verificați valorile returnate de funcții. În momentul verificării parametrilor de debit, există încă?
Vă mulțumim pentru link.
res = pthread_attr_init (atr);
attr .__ schedpolicy = SCHED_FIFO; # xA0; // SCHED_FIFO = 1
attr .__ schedparam.sched_priority = 5;
res = pthread_create (thread, attr, my_thread, fir);
res = pthread_getschedparam (fir, Politica, param);
printf ("rs =. # xA0; policy =. # xA0; prioritate =. \ n ", res, politică, # xA0; param.sched_priority);
Obtin rezultatul:
res = 0 politică = 0 prioritate = 0
De ce l-ai postat aici? )
Am reînceput deja de 5 ori, deoarece fluxurile mele cu filete atârnă sistemul strâns. Deși prioritatea trebuia să mă schimb))
#include
#include
#include
#include
#include
PTHREAD_MUTEX_INITIALIZER;
int a [2] =;
static void * my_thread (void * arg)
în timp ce (1) # xA0; pthread_mutex_lock (mutex);
# (int) arg] = a [(int) arg] + 1;
# xA0; pthread_mutex_unlock (mutex);
# xA0; pthread_yield ();
# xA0; somn (2); // Dacă aceasta este eliminată, atunci programul blochează sistemul;)
>
>
int principal (void)
pthread_t thread1, thread2;
int prioritate;
int politică, newprio;
struct sched_param param;
int ret;
printf ("... \ n", EPERM, EINVAL, ENOTSUP, ESRCH);
printf ("... \ n", SCHED_OTHER, SCHED_RR, SCHED_FIFO);
politică = SCHED_RR;
param.sched_priority = 2;
ret = sched_setscheduler (getpid (), politică, param);
dacă (ret == 0) # xA0; printf ("Stabilirea succesului procesului SCHED \ n");
> altfel dacă (ret == EPERM)
# xA0; printf ("Nicio permisiune \ n");
>
pthread_create (thread1, NULL, my_thread, (void *) (0));
pthread_create (thread2, NULL, my_thread, (void *) (1));
# xA0; # xA0; # xA0; # xA0; param.sched_priority = 2;
# xA0; # xA0; # xA0; # xA0; policy = SCHED_RR;
# xA0; # xA0; # xA0; # xA0; ret = pthread_setschedparam (thread1, politică, param);
# xA0; dacă (ret == 0) # xA0; printf ("Stabilirea succesului SCHED 1 \ n");
> altceva # xA0; printf ("Eșecul 1 \ n");
>
ret = pthread_getschedparam (thread1, Politica, param);
dacă (ret == 0) # xA0; printf ("Prioritatea Thread1 este. \ n", param.sched_priority);
>
# xA0; # xA0; # xA0; # xA0; param.sched_priority = 1;
# xA0; # xA0; # xA0; # xA0; policy = SCHED_RR;
# xA0; # xA0; # xA0; # xA0; ret = pthread_setschedparam (thread2, politică, param);
# xA0; dacă (ret == 0) # xA0; printf ("Stabilirea succesului SCHED 2 \ n");
> altceva # xA0; printf ("Eșecul 2 \ n");
>
ret = pthread_getschedparam (thread2, Politica, param);
dacă (ret == 0) # xA0; printf ("Prioritatea Thread2 este. \ n", param.sched_priority);
>
în timp ce (1) # xA0; pthread_mutex_lock (mutex);
# xA0; printf (". \ t. \ n", a [0], a [1]);
# xA0; pthread_mutex_unlock (mutex);
# xA0; usleep (5000);
>
Am făcut-o până acum. Încerc să văd vizual că un fir are o prioritate mai mare, dar până acum nu trebuie decât să repornești de fiecare dată când o pornesc :)
Ie când setați politica SCHED_RR sau SCHED_FIFO, firul cu cea mai mare prioritate va fi executat până când va fi forțat să renunțe (de exemplu, executând pthread_yield). Iată cum puteți asigura priorități diferite pentru firele cu politică SCHED_OTHER dacă nu puteți schimba prioritatea acolo, nu înțeleg :(
În general, după cum o înțeleg, aplicația trebuie să se controleze singură, deoarece vrea să aloce timpul între fire. Pentru alocarea exactă a timpului, există politici cu prioritate dinamică (SCHED_RR / SCHED_FIFO), pentru utilizarea necorespunzătoare a SCHED_OTHER fără posibilitatea de a seta prioritate dinamică la diferite fire.
În cele din urmă, iată ce am primit:
#include
#include
#include
#include
#include
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
static int thread_vars [2] =;
static safe_inc (int * x)
pthread_mutex_lock (mutex);
* x + = 1;
pthread_mutex_unlock (mutex);
>
static void * thread_proc (void * arg)
în timp ce (1)
# xA0; safe_inc (thread_vars [(int) arg]);
# xA0; dacă ((int) arg == 0) usleep (1);
>
>
int principal (void)
pthread_t thread1, thread2;
pthread_create (thread1, NULL, thread_proc, (void *) (0));
pthread_create (thread2, NULL, thread_proc, (void *) (1));
int x, y;
în timp ce (1)
# xA0; pthread_mutex_lock (mutex);
# xA0; x = thread_vars [0];
# xA0; y = thread_vars [1];
# xA0; pthread_mutex_unlock (mutex);
# xA0;
# xA0; printf (". \ t. \ n", x, y);
# xA0; usleep (100);
>
Ie Sunt create 2 fire și una dintre ele încetinește în mod artificial prin chemarea la usa. Cel de-al doilea primește automat o "prioritate mai mare".
Se pare că politica nu se schimbă deloc și este întotdeauna SCHED_OTHER. Curenții primesc un cuantum de timp, în funcție de parametrul funcției (1) plăcută, cu cât este mai mare valoarea acesteia, cu atât este mai mică cuantica. Acest lucru, desigur, nu este timp real, dar puteți trăi în felul acesta.
Mulțumesc pentru ajutor, mai ales pentru cei drăguți.
Politica mea se schimbă, dar cu politica rialtaymovoy aparent glumele sunt rele și nu am reușit să-l liniștesc. Și frumos schimbă prioritatea întregului proces, de aici puteți aloca prioritate dinamică altor procese și orice altceva, totul funcționează acolo. Desigur, cantitatile de timp alocate, de asemenea, depind de ea.
Sper că măcar ceva a ajutat :) Pentru mine, am învățat multe lucruri noi :)
A jucat un pic mai mult, dar deja pe countergaller, pentru care scriu programul. Iată ce se întâmplă:
1. În modul Utilizator, funcționează doar SCHED_OTHER. Asta am văzut ieri în Red Hat.
2. Alte politici funcționează în modul supervizor. În acest mod, execut procesul pe controler.
3. Cu cât este mai mare parametrul de prioritate, cu atât mai mare este prioritatea. Am crezut cumva contrariul.
Testul final pentru controler funcționează exact așa cum era de așteptat. În el, am eliminat întârzierea în fluxul cu prioritate scăzută, pentru că doar umbrește ce se întâmplă. În plus, nu sunt necesare nici mutexuri, deoarece operațiile cu int sunt atomice - atunci este int!
Iată textul (nu mi-a păsat întreruperea procesului prin intermediul Ctrl-C, deoarece controlerul se repornește destul de repede):
#include
#include
#include
#include
#include
static void * my_thread (void * arg)
int numb = (int) arg;
int politică;
struct sched_param param;
int count = 0;
int res;
politică = SCHED_FIFO;
dacă (numb == 0)
# xA0; param.sched_priority = 5;
altfel
# xA0; param.sched_priority = 10;
res = sched_setscheduler (getpid (), politică, param);
int principal (void)
pthread_t thread1, thread2;
int prioritate;
int politică, newprio;
struct sched_param param;
int ret;
ret = pthread_getschedparam (thread1, Politica, param);
politică = SCHED_FIFO;
param.sched_priority = 30;
ret = sched_setscheduler (getpid (), politică, param);
pthread_create (thread1, NULL, my_thread, (void *) 0);
pthread_create (thread2, NULL, my_thread, (void *) 1);
în timp ce (1) # xA0; printf (". \ t. \ n", a [0], a [1]);
# xA0; usleep (1000);
>
_uw_ # xA0; (03.01.07 10:27) [11]
A jucat un pic mai mult, dar deja pe countergiller
Asta este! De la o generație a ieșit :)
> _uw_ # xA0; (03.01.07 10:27) [11]
La mine acest cod închide sistemul :) Ei bine, de exemplu procesul consumă tot timpul procesorului, chiar și nimic nu poate fi transmis la consola, atunci totul se blochează, iar Alt + SysRq + b "salvează" numai. Nu înțeleg de ce și cum să o fac uman:
Sau politicienii rialtaymovye sunt calculați cu privire la ceea ce, cu excepția proceselor rialtaymovyh, nu ar trebui să se efectueze altele? Apoi, aparent pentru sarcinile obișnuite, este necesar să folosiți o pauză artificială așa cum am sugerat în [8]?
> Am acest sistem de agățat de cod
aveți niște kerneluri, cred. Puteți încerca să reduceți param.sched_priority.
așa cum este scris în om sched_setparam. Valoarea maximă a priorității poate fi obținută cu ched_get_priority_max
Da, am citit totul :) Și am încercat totul. Se blochează pentru orice valoare. Poate că kernelul a fost buggy desigur, dar mă îndoiesc profund. Chiar acum, de dragul experimentului, voi încerca pe celălalt nucleu.
Așa cum v-ați putea aștepta, 0 0 a fost scos și închis. (
deci ce vrei. Creați două fire cu prioritate ridicată, execuția cărora nu este întreruptă în nici un fel și doriți să imprimați ceva într-un fir cu prioritate scăzută
Suntem întrerupți de umezeală, dar acest lucru nu este suficient, în măsura în care înțeleg, orice proces cu politică în timp real va fi executat înainte de toate celelalte, prin urmare nu este posibilă utilizarea acestor politici pe sistemele desktop.
Există, în general, 3 fire, prioritatea principală fiind 30. Este clar că acestea nu lasă sistemului să aibă șansa de a obține cel puțin o bucată de timp CPU. Eu singur nu înțeleg de ce funcționează, în cuvintele lui :)
Memorie: 0,78 MB
Durată: 0,046 secunde
Articole similare
Trimiteți-le prietenilor: