Salut. Lucrind la un web server folosind libraria Conn (LGPL, la mine pe site) am trecut de la procese la thread-uri. Si am avut o surpriza mare. La profiling imi aparea o functie foarte des: __libc_disable_asynccancel, __libc_enable_asynccancel, __pthread_disable_asynccancel, __pthread_enable_asynccancel. Toate 4 in primele 15 intrari, ordonate dupa cit timp dureaza. Cea ce doare. Asa ca am cautat ce fac aceste functii. Se pare ca au treaba cu functia pthread_cancel; pare ca o tona de locuri din cod sint invelite in disable/enable cancel. Si asta costa. Cel putin se observa in valgrind, dar daca imi aduc aminte, am observat si la timpul de executie.
Deci, daca poti sa mergi cu procese, uita de thread-uri. Si procesele le poti mapa pe CPU-uri diferite cu pthread_attr_setaffinity_np. La thread-uri, poti partaza usor datele, dar trebuie sa ai grija cum. Foarte probabil o sa ai nevoie de functiile specifice de locking alre pthread sau de RCU (userspace-rcu, recomandat). -- Catalin(ux) M. BOIE http://kernel.embedromix.ro/ On Tue, 1 Sep 2015, Alex 'CAVE' Cernat wrote: > Salut > > Am mai lucrat cu multiprocess prin facultate, si de atunci pe ici pe > colo, treaba e simpla: fork() * n, n copii ale datelor, wait() & > friends, toata lumea fericita. > > Insa (mai nou ... sau mai vechi, ca e de multi ani), thread-urile au un > overhead mult mai mic decat procesele, dar din cate am inteles lucreaza > cu acelasi set de date, ceea ce nu e bine, pentru ca pe mine ma > intereseaza sa execut in paralel aceeasi bucata de cod dar pentru mai > multe seturi de date. > > Practic ma intereseaza sa paralelizez ceva de genul: > > operatii_de_inceput(); > for(i = 0; i <= N; i++) > operatii_in_paralel(i); <<<< paralelizare > operatii_de_final(); > > in cazul meu operatiile de final (daca exista) nu se bazeaza pe cele in > paralel (decat cel mult niste coduri de ok / eroare), astfel incat cu > procese le-as putea scoate usor, dar daca se poate cu thread-uri si e > mai performant ... de ce nu ? > > problema la care nu-i dau de cap (cel mai probabil pentru ca nu am > inteles inca prea bine cum functioneaza threadurile) este cum fac o > copie locala a unei variabile, astfel incat variabila respectiva sa aiba > valorea doar pentru threadul respectiv, in alt thread putand avea o alta > valoare, iar o asignare a acelei variabile intr-un thread sa nu > influenteze valoarea aceleiasi variabile dintr-un altul > > rezumand, in principiu ma intereseaza daca se poate face exact acelasi > lucru ce as putea sa fac cu multiproces ('copie' a datelor), dar > folosind threaduri (cel putin unele variabile sa fie 'locale' threadului) > > Mersi > Alex > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
