„Bună, Amigo! Vreau să vă spun despre partajarea resurselor. În diferite fire, firește.
„Vorbesc în continuare despre problemele care apar atunci când lucrezi cu mai multe fire de execuție și despre cum să le rezolvi. Acest lucru nu înseamnă că folosirea thread-urilor este proastă. Thread-urile sunt un instrument foarte puternic. De fapt, ele vă permit să vă faceți programul mai rapid și chiar mai fiabil. Cu cât un program este mai complex, cu atât are mai multe fire și diverse părți independente."
„Divizarea unui program în părți independente (cuplate liber) este foarte benefică.”
"Imaginați-vă că programul dvs. este împărțit intern în 100 de fire de execuție. Dar aveți doar un procesor dual-core. Aceasta înseamnă că, în medie, 50 de fire de execuție vor fi executate pe fiecare nucleu."
„Dacă aveți nevoie să creșteți performanța programului, cumpărați doar un server cu dublu procesor și câteva procesoare dulci pentru acesta. Acest lucru vă poate aduce până la 32 de nuclee, ceea ce duce la o creștere de 2-20 de ori a performanței. În funcție de număr. din părți cu adevărat independente în care este împărțit.”
"Acesta este unul dintre motivele pentru care Java domină în dezvoltarea întreprinderilor. Dacă o companie are un program intern complex scris de 20 de dezvoltatori, atunci este mult mai ieftin să cumperi un alt server decât să dublezi performanța programului prin optimizare."
— Deci despre asta e vorba.
"Dar! De fiecare dată când un dezvoltator decide să folosească un alt thread, el rezolvă o problemă și creează două. Tot mai multe fire nu vor crește la nesfârșit performanța programului."
"În primul rând, orice program are o activitate care nu poate fi defalcată și rulată în paralel pe fire diferite. În al doilea rând, toate firele de execuție sunt executate pe același procesor. Cu cât aveți mai multe fire de execuție, cu atât mai lent funcționează fiecare."
„Și, cel mai important, firele de execuție folosesc adesea aceleași obiecte (numite de obicei „resurse partajate”).”
„De exemplu, un thread vrea să salveze informații despre munca pe care a finalizat-o într-un fișier. Dacă există mai multe astfel de fire și doresc să scrie informații în același fișier, acestea vor interfera între ele. Pentru a preveni ca fișierul să devină un mizerie amestecată, accesul la fișier este limitat, adică în timp ce un fir folosește fișierul, alții așteaptă."
"Da, îmi amintesc. Faceți asta folosind cuvântul cheie sincronizat ."
"Ai perfecta dreptate."
„Și ce se întâmplă dacă firele scriu în fișiere diferite?”
„În mod formal, acestea sunt obiecte diferite, dar probabil că sunt pe același hard disk”.
„Deci, este cu adevărat posibil să paralelizezi ceva în interiorul procesorului?”
„Tehnic, da, dar de îndată ce firul tău are nevoie de ceva în afară de datele pe care le are, acel ceva s-ar putea să fie deja ocupat de un alt thread – și firul tău va trebui să aștepte.”
"Ei bine, ce ar trebui să fac atunci? De unde știu dacă ar trebui să fac multe fire sau nu?"
„Acest lucru este determinat direct de arhitectura programului dumneavoastră. Fiecare proiect are propriul „arhitect” care cunoaște toate „resursele” utilizate în program, cunoaște limitele acestora și cât de bine/prost sunt paralelizate.”
— Și dacă nu știu?
„Există două opțiuni:”
a) lucrează sub supravegherea cuiva care o face
b) fă niște bulgări să-ți dai seama singur
„Sunt un robot: nu am bulgări, ci doar lovituri”.
— Ei bine, atunci, fă niște lovituri.
— Înțeleg. Mulțumesc. Ai clarificat câteva lucruri despre care începusem deja să mă întreb.
GO TO FULL VERSION