La lliçó anterior va parlar tota l'estona de «fluxos d'execució» sense comprometre's amb què eren. Ara toca concretar. Al mòdul 2 vas conèixer el procés: la seva imatge de memòria, el seu task_struct, el seu espai d'adreces privat protegit per la MMU. Un procés és una unitat de dues coses alhora: possessió de recursos (memòria, fitxers oberts, credencials) i execució (un comptador de programa avançant pel codi).

La idea del fil consisteix a separar aquestes dues coses. Un procés continua sent l'amo dels recursos, però pot tenir diversos fluxos d'execució a dins, compartint tot el que el procés posseeix. Això abarateix brutalment la creació i la comunicació —i a canvi elimina la xarxa de seguretat de la MMU entre ells, que és exactament per què existeix la resta d'aquest mòdul.

En acabar sabràs amb precisió què comparteixen i què no comparteixen els fils germans, quant costa cada operació en microsegons reals, com implementa Linux els fils (una resposta sorprenent: no els implementa; implementa clone()), com es programa amb fils POSIX en C i amb threading en Python, què és realment el GIL sense mites, i com triar entre procés, fil i bucle d'esdeveniments per a cada peça de Meteora.

1. Què és un fil i quina és la seva unitat mínima privada
2. Què comparteix i què no comparteix un fil amb els seus germans
3. El bloc de control del fil
4. Per què existeixen els fils: els números
5. Models d'implementació: N:1, 1:1 i M:N
6. Com ho fa Linux de debò: clone()
7. Inspeccionar fils des de fora: ps -eLf i /proc/<pid>/task/
8. Fils POSIX en C: l'ingestor amb quatre fils
9. Fils en Python, el GIL i multiprocessing
10. Grups de fils: per què gairebé mai no es creen a mà
11. Procés per connexió, fil per connexió i asíncron a meteo-api
12. Criteris d'elecció entre fils i processos
13. Terminació i cancel·lació de fils

Un fil (thread, o fil d'execució) és la unitat bàsica d'ús de la CPU: un flux seqüencial d'instruccions dins d'un procés. Un procés tradicional té exactament un fil; un procés multifil en té diversos executant-se sobre el mateix espai d'adreces.

La pregunta clau per entendre-ho és: quina és la quantitat mínima d'estat que necessita un flux d'execució per ser independent d'un altre? La resposta és curta:

• Un comptador de programa (%rip): on està executant ara mateix.
• Un joc de registres: les seves variables en curs.
• Una pila pròpia: les seves variables locals, els seus paràmetres i la seva cadena de crides.

Res més. Tota la resta —el codi, les dades globals, el munt, els fitxers oberts, la taula de pàgines— es pot compartir sense que els fluxos deixin de ser independents.

Aquesta pila pròpia mereix un moment d'atenció, perquè és la part que més s'oblida. Si dos fils compartissin la pila, la crida a funció d'un trepitjaria el marc de l'altre i el programa es destruiria en microsegons. Per això cada fil rep la seva pròpia regió de pila dins de l'espai d'adreces compartit: a Linux, 8 MB d'espai virtual reservat per fil per defecte (ulimit -s), tot i que només es materialitzen les pàgines físiques que s'utilitzen de debò, gràcies a l'assignació sota demanda que vas veure al mòdul 2.

El diagrama conté tota la lliçó en una imatge: tres fluxos amb el mínim privat, surant sobre un oceà de memòria comuna. Aquest oceà és el que fa els fils ràpids i perillosos a parts iguals.

Aquesta taula és la referència que consultaràs una vegada i una altra. Val la pena llegir-la sencera amb atenció, perquè cada fila té una conseqüència pràctica.

Quatre files mereixen desenvolupament perquè són font constant d'errors.

errno és local al fil, i ho ha de ser. Si fos global, dos fils fent crides al sistema simultànies es trepitjarien el codi d'error i cap programa multifil no podria comprovar errors de manera fiable. La solució va ser convertir-lo en una macro: a glibc, #define errno (*__errno_location()), on __errno_location() retorna un punter diferent per fil, obtingut del bloc TLS al qual apunta el registre de segment %fs. Per això errno «funciona» en programes multifil sense que hi facis res, i per això no pots fer int *p = &errno; en un fil i usar-lo des d'un altre.

Les senyals són del procés, però la màscara és del fil. Aquesta asimetria causa molta confusió. Hi ha una única taula de gestors: si un fil instal·la un gestor per a SIGHUP, l'instal·la a tothom. Però cada fil té la seva pròpia màscara de senyals bloquejades, i quan arriba una senyal dirigida al procés, el nucli tria un fil qualsevol que no la tingui bloquejada. Això vol dir que no saps quin fil l'atendrà. El patró professional consisteix a bloquejar la senyal a tots els fils i dedicar-ne un a rebre-les amb sigwait(). Ho veurem aplicat a la recàrrega d'/etc/meteora/meteora.conf a Comunicació entre Processos (IPC).

La taula de descriptors compartida és una arma de doble tall. És còmode: el fil 1 accepta un socket i el fil 2 l'atén. Però si el fil 1 fa close(fd) mentre el fil 2 és en un read(fd), i el nucli reassigna aquell número a un fitxer nou, el fil 2 llegeix del fitxer equivocat. És una de les carreres més difícils de trobar en servidors reals.

L'emmagatzematge local del fil (TLS) és la via d'escapament quan vols una «global» que no es comparteixi. En C n'hi ha prou amb __thread (o _Thread_local en C11): __thread unsigned long peticions_daquest_fil = 0; dona una còpia per fil, sense sincronització. És la tècnica que sosté el consell de la lliçó anterior: no compartir és millor que sincronitzar bé. Si cada treballador de meteo-api porta el seu comptador en TLS i algú els suma un cop per minut, la secció crítica desapareix.

Igual que cada procés té el seu bloc de control (el task_struct del mòdul 2), cada fil necessita el seu: el TCB (Thread Control Block). Conté exactament el que la taula anterior va marcar com a «no compartit»: el TID; l'estat (executant, llest, bloquejat, els mateixos del mòdul 2); el context de registres (%rip, %rsp, generals i SIMD); la base i la mida de la seva regió de pila; les dades del planificador (vruntime, política, nice); la seva màscara de senyals; el punter al seu bloc TLS; i un punter al PCB del procés, que és per on arriba a tot allò compartit.

La relació és jeràrquica: un PCB, diversos TCB apuntant-hi. I aquí és on el disseny es torna interessant a Linux, perquè Linux no fa exactament això, com veurem a l'apartat 6.

La justificació dels fils és purament quantitativa. Aquestes són mesures sobre meteo-01 (Linux 6.1, Xeon a 3,0 GHz), obtingudes amb microbenchmarks de 100.000 repeticions:

Les raons de cada diferència són concretes i es recolzen en el que ja saps del mòdul 2:

Creació. fork() ha de duplicar el mm_struct, recórrer totes les àrees de memòria (VMA) del procés, copiar la taula de pàgines marcant-ho tot com a copy-on-write, i duplicar la taula de descriptors. Un clone() que comparteix mm se salta tot això: incrementa un comptador de referències i ja està. Com més gran sigui el procés, més gran la diferència: un procés amb 2 GB mapejats triga molt més a fer fork() que un amb 10 MB, mentre que crear un fil costa el mateix en tots dos casos.

Canvi de context. Aquí la clau és el TLB. Canviar entre processos exigeix carregar %cr3 amb una altra taula de pàgines, cosa que invalida les entrades del TLB (mitigat, però no eliminat, pels identificadors PCID de les CPU modernes). Després vénen desenes o centenars de fallades de TLB mentre el procés nou s'escalfa. Entre fils del mateix procés, %cr3 no canvia: el TLB i les memòries cau continuen sent vàlids. Aquesta és la major part del factor 3.

Comunicació. Una dada compartida entre fils no s'«envia»: hi és. Passar un punter a una memòria intermèdia d'1 MB costa 8 bytes. Entre processos s'ha de copiar a través del nucli (dues còpies: usuari→nucli→usuari) o muntar memòria compartida explícitament.

Aquests números expliquen per què l'ingestor de Meteora fa servir fils i no processos per processar lots: crea 4 fluxos en 88 µs en lloc de 720 µs, i sobretot es passa l'array de Lectura sense copiar 17 MB.

Un fil el pot gestionar la biblioteca en espai d'usuari, el nucli, o tots dos. Històricament hi ha hagut tres models.

N:1, fils d'usuari. Tota la gestió passa en una biblioteca d'espai d'usuari. El nucli veu un únic procés amb un únic fil i no en sap res. La biblioteca desa registres, canvia la pila i salta: un canvi de «context» costa ~100 nanosegons, sense crida al sistema.

1:1, fils de nucli. Cada fil d'usuari correspon a una tasca planificable pel nucli. El nucli els coneix, els planifica individualment i els reparteix entre nuclis.

M:N, híbrid. M fils d'usuari es multiplexen sobre N fils de nucli, amb dos nivells de planificació.

El defecte letal de N:1 és la tercera fila des de baix: si un fil fa read() sobre un socket i es bloqueja, el nucli bloqueja tot el procés, perquè només veu un fil. Els altres 99 fils, encara que tinguessin feina, es queden aturats. Combinat amb la impossibilitat d'usar diversos nuclis, va condemnar el model per a ús general.

M:N resol tots dos problemes sobre el paper, però és endimoniadament complex: cal interceptar totes les crides bloquejants per migrar el fil lleuger a un altre portador, i els dos planificadors prenen decisions que es contradiuen. Solaris el va implementar als anys 90 i el va acabar abandonant per 1:1. Linux ho va intentar (el projecte NGPT d'IBM) i també ho va descartar.

L'interessant és que M:N ha tornat per la porta dels llenguatges, no del sistema operatiu: les goroutines de Go i els fils virtuals de Java 21 són M:N implementats al runtime del llenguatge, que sí que controla tots els punts de bloqueig perquè controla tota la biblioteca estàndard. És la mateixa idea amb la peça que faltava.

Linux va triar 1:1 amb NPTL (Native POSIX Thread Library, 2003) apostant per fer els fils de nucli tan barats que no compensés complicar-se. Els 22 µs de la taula anterior són el resultat d'aquella aposta.

Aquí arriba la part que sorprèn gairebé tothom: el nucli de Linux no té un concepte de «fil». Té tasques (task_struct), i cada tasca decideix què comparteix amb la seva creadora. Un «fil» és simplement una tasca que comparteix l'espai d'adreces; un «procés» és una tasca que no el comparteix. La mateixa crida al sistema crea tots dos: clone().

Els flags són el que decideix què es comparteix:

Amb aquests flags, les dues operacions clàssiques són només dues combinacions: fork() és clone(SIGCHLD, ...) —no comparteix res—, i pthread_create() és clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|..., pila, ...). Es comprova amb strace:

Aquí hi ha tot: la llista de flags, la pila de 8 MB (0x7ffa80 bytes) reservada per la biblioteca, i el TID 4312 retornat.

Aquesta unificació té tres conseqüències molt pràctiques:

1. El planificador CFS planifica fils, no processos. Quan al mòdul 2 vam parlar de vruntime i de repartir la CPU, la unitat era la tasca. Un procés amb 8 fils rep, per defecte, 8 vegades més CPU que un procés monofil que hi competeixi.
2. La frontera és un continu, no un mur. Pots crear una tasca que comparteixi la memòria però no els descriptors, o que comparteixi els descriptors però no la memòria. Els contenidors exploten precisament aquesta flexibilitat amb els flags CLONE_NEW* (mòdul 6).
3. A /proc els fils existeixen i es veuen. Cadascun té el seu directori, com veurem ara.

Un ps -ef normal amaga els fils: mostra un procés, encara que tingui vint fluxos a dins. L'opció -L els revela:

Com es llegeix:

• PID 2841 per a les cinc files: és un únic procés.
• LWP (Light Weight Process) és el TID de cada fil. Són diferents: 2841, 2843, 2844, 2845, 2846.
• NLWP = 5: cinc fils en total.
• El fil el TID del qual coincideix amb el PID (2841) és el fil principal, el que va arrencar a main(). El seu temps de CPU és de 3 segons davant dels 4 minuts dels altres: és el fil que accepta connexions i les reparteix, mentre els quatre treballadors fan la feina real.

A /proc l'estructura és igual d'explícita:

Un directori per fil, amb el seu propi stat, el seu propi status, la seva pròpia stack. Fixa't que cada fil té els seus comptadors de temps i el seu nucli actual. El que no hi trobaràs és un maps diferent per fil: /proc/2841/task/2844/maps és idèntic a /proc/2841/maps, perquè el mapa de memòria és del procés. És la demostració pràctica de la primera fila de la taula de compartició.

Un truc molt útil per diagnosticar: top -H mostra fils en lloc de processos, i és la manera ràpida de descobrir que «el procés està al 400 %» en realitat vol dir «un fil està al 100 % i tres al 100 %» o bé «un fil està al 400 %... impossible, per tant són quatre». Hi tornarem a Monitoratge i Diagnòstic de Rendiment.

Anem amb codi real. L'ingestor rep lots de lectures i les ha de validar i convertir abans d'escriure-les a /var/lib/meteora/lectures/. És una feina perfectament divisible: cada lectura és independent de les altres.

Es compila amb gcc -O2 -pthread ingestor_fils.c -o ingestor_fils. El flag -pthread és obligatori: defineix _REENTRANT i enllaça la biblioteca, i oblidar-lo produeix fallades incomprensibles.

Punts de disseny que convé entendre bé, perquè són el patró correcte:

Tots els fils reben el mateix punter lot. No es copia res. 17 MB de lectures compartits pel cost de quatre punters de 8 bytes. Això és exactament el que fa barats els fils.

Cada fil té un rang disjunt. El fil 0 toca [0, 175000), l'1 toca [175000, 350000), etc. No hi ha dos fils que escriguin la mateixa posició, així que no hi ha condició de carrera malgrat compartir l'array. És la tècnica més important d'aquesta lliçó: partir les dades en lloc de protegir les dades.

El resultat de cada fil va al seu propi struct Tros. Si els quatre fessin total_global++, tindríem exactament la carrera de la lliçó anterior. En escriure cadascun a la seva estructura i sumar al fil principal després dels pthread_join, la suma és segura sense cap primitiva de sincronització.

pthread_join compleix dues funcions: espera que el fil acabi i allibera els seus recursos (pila i TCB). Un fil que acaba i del qual ningú no fa join es queda com a zombi de fil consumint memòria, igual que els processos zombi del mòdul 2. Si no penses esperar un fil, crea'l desprès (pthread_detach o l'atribut PTHREAD_CREATE_DETACHED) perquè s'autoalliberi.

El pthread_create es comprova per valor de retorn, no per errno. És una peculiaritat de l'API de pthreads: les funcions retornen directament el codi d'error i no toquen errno. Escriure if (pthread_create(...) < 0) perror(...) és un error clàssic que no detecta res.

Rendiment mesurat sobre les 700.000 lectures del fitxer 2026-08-31.dat:

3,49× de 4 possible: eficiència del 87 %. És un cas gairebé ideal precisament perquè no hi ha estat compartit escrit. Tan bon punt calgui sincronitzar, el número baixarà.

Python té fils reals del sistema operatiu: threading.Thread acaba cridant pthread_create. Però l'intèrpret CPython té el GIL (Global Interpreter Lock), un forrellat global que garanteix que només un fil executa bytecode de Python alhora.

Abans dels mites, la raó que existeixi. La gestió de memòria de CPython fa servir recompte de referències: cada objecte porta un comptador que s'incrementa i es decrementa contínuament. Aquest comptador és un read-modify-write, exactament la carrera de la lliçó anterior. Sense protecció, dos fils manipulant el mateix objecte corromprien el comptador i provocarien alliberaments prematurs o fuites. Les opcions eren un forrellat per objecte (lent pel cost de les operacions atòmiques i arriscat per interbloqueigs) o un sol forrellat global (simple i rapidíssim per a codi monofil). CPython va triar la segona opció el 1992 i arrossega la decisió des d'aleshores.

L'essencial i el que gairebé ningú no diu bé: el GIL s'allibera durant les operacions d'E/S i durant les crides a codi C que el deixen anar explícitament. Això parteix el món en dos:

Resultats a meteo-01 (8 nuclis, CPython 3.11):

Llegeix-ho amb calma, perquè cada línia diu alguna cosa:

Les conclusions pràctiques, sense mites:

• «Els fils de Python són inútils» és fals. Per a feina dominada per E/S —que és la major part del codi de servidor— escalen perfectament. L'ingestor esperant 800 sockets és un cas ideal per a threading.
• «Els fils de Python donen paral·lelisme de CPU» també és fals. Per calcular, cal fer servir multiprocessing, o biblioteques que deixin anar el GIL al seu codi C (NumPy, pandas, hashlib, la compressió de zlib), o extensions pròpies.
• Afegir fils a codi CPU-bound el fa més lent, no només igual. La contenció del GIL té cost.

El cost de multiprocessing és que els arguments i els resultats se serialitzen amb pickle i viatgen per una canonada. Per a 17 MB de lectures això són uns 180 ms d'anada i uns altres tants de tornada: si el càlcul dura menys que això, surt a perdre. L'alternativa és multiprocessing.shared_memory, que és memòria compartida POSIX i la veurem a Comunicació entre Processos (IPC).

Un apunt de futur que convé conèixer: Python 3.13 va introduir una compilació experimental sense GIL (PEP 703, free-threading), que substitueix el forrellat global per recompte de referències esbiaixat i forrellats per objecte. Quan s'estabilitzi, la taula anterior canviarà. Fins llavors, el criteri continua sent el de dalt.

Els exemples anteriors creen fils, treballen i els destrueixen. En un servidor real això és un error, per tres raons:

1. Cost de creació repetit. 22 µs per fil sembla poc, però a 1.200 peticions per segon són 26 ms per segon, un 2,6 % d'un nucli llençat en administratiu.
2. Sense límit de concurrència. Un fil per petició significa que un pic de 5.000 peticions simultànies crea 5.000 fils, 40 GB d'espai virtual de pila i un planificador que es passa més temps canviant de context que treballant. És el thread explosion, i tomba servidors.
3. Sense control de recursos. Cada fil pot obrir descriptors, reservar memòria i contactar amb la base de dades. Sense sostre, no hi ha dimensionament possible.

La solució és el grup de fils (thread pool): un nombre fix de fils creats en arrencar que consumeixen tasques d'una cua compartida.

Què guanya aquest codi respecte a crear 80 fils:

• Es creen 8 fils una vegada, no 80. El cost de creació s'amortitza entre totes les tasques.
• El paral·lelisme està acotat a 8. Les estacions no reben 80 connexions de cop, i el procés no dispara el seu consum.
• La cua actua d'amortidor. Si arriben tasques més ràpid del que es processen, s'encuen en lloc de crear fils. És un mecanisme de contrapressió natural.
• El with garanteix el join de tots els fils en sortir, fins i tot si hi ha una excepció.

Dimensionar el grup té una regla útil. Per a feina de CPU, la mida òptima és el nombre de nuclis (més fils només afegeixen canvis de context). Per a feina d'E/S, la fórmula clàssica és:

Per a meteo-api: 8 nuclis, cada petició triga 0,4 ms de CPU i espera 12 ms a la base de dades. Surt 8 × (1 + 12/0,4) = 8 × 31 = 248 fils. Aquest número, i el fet que sigui tan gran, és justament el que motiva l'apartat següent.

meteo-api ha d'atendre consultes HTTP. Hi ha tres arquitectures clàssiques i l'elecció ho condiciona tot.

Un procés per connexió. El servidor fa accept() i fork() —while(1){ int cli=accept(...); if(fork()==0){close(escolta); atendre(cli); _exit(0);} close(cli); }—. És el model d'inetd i d'Apache prefork. Màxim aïllament: si atendre una petició provoca una fallada de segment, mor només aquell procés. Cost: 180 µs i ~1,4 MB per connexió; amb 1.000 connexions simultànies, 1,4 GB només de processos.

Un fil per connexió. Igual, però amb pthread_create. 22 µs i uns 12 KB reals per connexió (encara que 8 MB virtuals). És el model d'Apache en mode worker i de la majoria de servidors Java tradicionals. Aguanta bé fins a uns pocs milers de connexions; a partir d'aquí, la memòria i el canvi de context es mengen la màquina.

Asíncron amb un bucle d'esdeveniments. Un sol fil (o un per nucli) que vigila milers de descriptors amb epoll i atén el que estigui llest. És el model de nginx, Node.js i asyncio.

Cada await és un punt on la corutina cedeix el control al bucle, que atén una altra connexió mentre aquesta espera. El cost per connexió baixa a uns 2-5 KB i no hi ha canvis de context del nucli.

La fila que més decisions determina és la penúltima: en el model asíncron, una crida bloquejant o un càlcul llarg congela el servidor sencer. Un time.sleep(1) en lloc d'await asyncio.sleep(1) dins d'una corutina atura les 10.000 connexions durant un segon. És la fallada número u en codi asíncron, i no dona error: només latència inexplicable.

La decisió de Meteora, ara justificada: meteo-api fa servir un grup de 8 fils perquè cada petició fa consultes a la memòria cau que triguen mil·lisegons i el nombre de clients simultanis és de centenars, no de desenes de milers; l'aïllament no compensa el cost de processos. L'ingestor, en canvi, manté 800 connexions permanents que estan gairebé sempre inactives —cada estació envia un cop per minut—: és el cas perfecte per a epoll asíncron, perquè 800 fils adormits serien 800 piles i 800 tasques al planificador per a res.

A Meteora, ingestor, agregador i meteo-api són processos separats per tres raons acumulades: si l'agregador falla processant un fitxer corromput, l'API continua servint; l'ingestor necessita permisos d'escriptura a /var/lib/meteora/lectures/ que l'API no ha de tenir; i demà l'agregador es podria moure a una altra màquina sense canviar res del disseny. Dins de cada procés, fils, perquè allà la feina comparteix dades i l'aïllament no aporta res.

Un fil pot acabar de quatre maneres: fent return de la seva funció (el valor el recull pthread_join); cridant pthread_exit(valor), igual però des de qualsevol profunditat de la pila; rebent un pthread_cancel(tid) d'un altre fil; o perquè qualsevol fil del procés cridi exit().

Aquesta última possibilitat és crítica i sorprèn: exit() no acaba el fil, acaba el procés sencer. Si un fil treballador crida exit(1) en detectar un error, s'emporta per davant els altres tres i les peticions que estiguessin atenent. En un fil treballador es fa return NULL o pthread_exit(), mai exit().

La cancel·lació és el mecanisme més delicat de pthreads. pthread_cancel(tid) no mata el fil: envia una sol·licitud que el fil atén segons la seva configuració. Amb el tipus PTHREAD_CANCEL_DEFERRED (el de per defecte), només té efecte en arribar a un punt de cancel·lació: read, write, sleep, pthread_cond_wait, accept i unes desenes més de funcions que es poden bloquejar. Amb PTHREAD_CANCEL_ASYNCHRONOUS, en qualsevol instrucció, cosa que és gairebé sempre una mala idea: el fil pot morir amb un mutex pres o amb memòria a mig reservar. I un fil la pot rebutjar temporalment amb pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &vell) mentre fa alguna cosa indivisible.

El problema de fons és la neteja: si el fil mor enmig d'una funció, qui allibera el que havia reservat? Existeixen pthread_cleanup_push/pop per registrar gestors, però és un mecanisme fràgil i fàcil d'oblidar. Per això la pràctica professional evita pthread_cancel i fa servir terminació cooperativa: una bandera que el fil consulta i un mecanisme per despertar-lo si està bloquejat.

El fil decideix quan parar, en un punt on sap que el seu estat és consistent. És més codi, però és l'únic enfocament que funciona de manera fiable. I la bandera, per ser del tot correcta, hauria de ser un atomic_int, no un volatile: ho justificarem a Sincronització i Exclusió Mútua.

Oblidar -pthread en compilar. Sense això, glibc pot enllaçar versions no reentrants d'algunes funcions i errno pot no ser local al fil. Els símptomes són aleatoris i inexplicables. És -pthread (no -lpthread), i va tant en la compilació com en l'enllaçat.

Comprovar errors de pthreads amb errno. Les funcions pthread_* retornen el codi d'error com a valor de retorn i no toquen errno. El correcte és int rc = pthread_create(...); if (rc != 0) fprintf(stderr, "%s\n", strerror(rc));.

Passar l'adreça d'una variable de bucle al fil. L'error clàssic: for (int i=0;i<4;i++) pthread_create(&h[i], NULL, f, &i);. Els quatre fils reben el mateix punter i llegeixen el valor d'i quan els toca executar, que pot ser 4 en tots. Passa un punter a un element d'un array que sobrevisqui (com el trossos[i] de l'exemple) o el valor convertit a void *.

No fer join ni detach. El fil acabat conserva el seu TCB i la seva pila fins que algú en reculli l'estat. En un servidor que crea fils contínuament, això és una fuita de memòria que creix fins a esgotar la màquina.

Cridar exit() des d'un fil treballador. Mata el procés sencer. Fes servir return o pthread_exit().

Fer servir funcions no reentrants. strtok, asctime, getpwnam, gmtime o rand guarden estat en variables estàtiques compartides i retornen brossa si dos fils les criden alhora. Fes servir sempre les variants _r: strtok_r, gmtime_r, getpwnam_r, rand_r.

Consell: parteix les dades abans que protegir les dades. L'exemple de l'ingestor assoleix 3,49× de 4 possible sense ni una sola primitiva de sincronització, perquè cada fil treballa sobre un rang disjunt i escriu el seu resultat a la seva pròpia estructura. Quan puguis particionar, particiona: és més ràpid i no pot fallar.

Consell: posa nom als teus fils. pthread_setname_np(pthread_self(), "api-worker-2") (màxim 15 caràcters) fa que top -H, ps -eLf i gdb mostrin noms llegibles en lloc de repetir el de l'executable. Quan estiguis depurant una penjada a les tres de la matinada, ho agrairàs.

Consell: no creïs fils per feina, crea un grup. El cost de creació, el risc d'explosió de fils i la manca de contrapressió fan que crear fils sota demanda sigui gairebé sempre un error en un servei.

Escriu un programa en C amb dos fils que comprovi experimentalment tres afirmacions de la taula de compartició: (a) una variable global és compartida, (b) una variable local de la funció del fil és privada, (c) una variable __thread és privada encara que sigui global. A més, imprimeix des de cada fil el seu TID (gettid()) i el seu PID (getpid()) per comprovar que el PID coincideix. Verifica el resultat amb ls /proc/<pid>/task/.

Escriu un programa en Python que mesuri el temps d'una tasca de CPU (per exemple, comptar quantes d'un milió de Lectura simulades són vàlides) amb 1, 2, 4 i 8 fils fent servir threading, i amb 1, 2, 4 i 8 processos fent servir multiprocessing. Construeix la taula comparativa i explica cada columna. Després repeteix l'experiment de fils substituint el càlcul per time.sleep(0.25) i compara.

Meteora vol afegir un component nou, meteo-alertes, que manté una connexió WebSocket oberta amb cada client subscrit per enviar-li avisos de temperatura extrema. S'esperen 15.000 clients connectats simultàniament, amb molt poc trànsit (un missatge cada uns quants minuts), i cada missatge requereix 0,2 ms de CPU. Tria entre procés per connexió, fil per connexió i asíncron. Justifica-ho amb números de memòria i de canvis de context, i calcula quanta CPU total consumiria el servei.

Solució 1

Sortida típica:

Anàlisi línia a línia:

• global: el fil 1 veu 5, el fil 2 veu 10 (els seus més els de l'altre), i main veu 10. És compartida. Els valors intermedis varien entre execucions, perquè global++ és la carrera de la lliçó anterior; amb més iteracions el total final seria menor que 10.
• local: tots dos veuen 5, i les seves adreces difereixen en uns 8 MB (0x7f3a4bff8e5c davant de 0x7f3a4b7f7e5c, exactament la mida de pila per defecte). Cada fil té la seva pròpia pila, i la separació entre elles confirma la reserva de 8 MB per fil.
• tls: tots dos fils veuen 5, i main veu 0, encara que tls està declarada com a global. __thread crea una còpia per fil, i el fil principal té la seva.
• PID idèntic (5120), TID diferents (5120, 5121, 5122): un procés, tres tasques; el TID del fil principal coincideix amb el PID. I mentre dormen, ls /proc/5120/task/ llista exactament aquests tres TID.

Solució 2

Resultats a meteo-01 (8 nuclis):

Columna «fils CPU»: el temps creix linealment amb el nombre de fils, i una mica més que linealment (2,81 s davant dels 2,48 s que serien 8×0,31). No hi ha cap paral·lelisme: els fils es van tornant el GIL, que se cedeix cada 5 ms per defecte (sys.setswitchinterval()), i aquest tragí afegeix un 13 % de sobrecost. Vuit fils fan la feina de vuit, un darrere l'altre, pagant a més el peatge.

Columna «procs CPU»: el temps amb prou feines puja (0,36 → 0,52 s) perquè els 8 processos corren de debò als 8 nuclis, cadascun amb el seu propi GIL. La pujada que hi ha es deu a l'arrencada dels processos i a la serialització, no al càlcul. Amb 8 processos es fa vuit vegades més feina en 1,4 vegades més temps: 5,5× d'acceleració efectiva.

Columna «fils E/S»: constant en 0,25 s amb 1 i amb 8 fils. time.sleep() allibera el GIL, així que les vuit esperes transcorren simultàniament. És l'escenari en què threading és exactament l'eina correcta.

Regla que se'n dedueix: a CPython, threading per esperar i multiprocessing per calcular.

Solució 3

Dades: 15.000 connexions simultànies, un missatge cada 5 minuts per client, 0,2 ms de CPU per missatge.

Càrrega real de CPU. 15.000 clients / 300 s = 50 missatges/s. A 0,2 ms cadascun: 10 ms de CPU per segon, l'1 % d'un nucli. El servei no té cap problema de càlcul: el seu problema és mantenir 15.000 connexions inactives.

Procés per connexió. 15.000 × 1,4 MB = 21 GB de RSS, impossible a meteo-01, més 15.000 processos a la cua del planificador. Descartada.

Fil per connexió. 15.000 × 12 KB de pila materialitzada = 180 MB de RSS, més uns 10 KB de task_struct i pila de nucli per fil: 150 MB més. Total ~330 MB per usar l'1 % d'un nucli. Funciona, però manté 15.000 tasques al planificador, gairebé totes bloquejades en read(), i cada despertar arrossega migracions entre nuclis i fallades de memòria cau.

Asíncrona. Un descriptor i uns 3 KB d'estat per connexió: 45 MB, un únic fil, zero canvis de context entre connexions. epoll_wait() retorna només els descriptors llestos, així que el cost és O(esdeveniments), no O(connexions). Amb 50 esdeveniments per segon, el bucle està pràcticament adormit.

Elecció: asíncron, i no està renyit amb res. És el cas de llibre per a un bucle d'esdeveniments: moltíssimes connexions, gairebé totes inactives, molt poc càlcul per missatge. És exactament el mateix perfil que l'ingestor amb les seves 800 estacions, i la mateixa raó per la qual nginx atén centenars de milers de connexions en una màquina modesta.

L'única precaució, i cal prendre-se-la seriosament: cap operació del gestor no pot bloquejar. Si en detectar una alerta cal escriure a la base de dades, aquesta escriptura ha de ser asíncrona o delegar-se a un petit grup de fils amb run_in_executor(). Un INSERT síncron de 40 ms congelaria les 15.000 connexions durant aquest temps.

Un fil és la unitat d'execució dins d'un procés, i el seu estat privat mínim és sorprenentment petit: comptador de programa, registres i pila pròpia. Tota la resta ho comparteix amb els seus germans: l'espai d'adreces, la taula de descriptors, el directori de treball, les credencials meteora:meteora, els gestors de senyal i els mapatges com /dev/shm/meteora-cache. En queden fora, a més de la pila i els registres, el TID, la màscara de senyals, la prioritat i errno, que des del 1995 és una macro sobre emmagatzematge local del fil precisament perquè un errno global faria impossible programar amb fils.

Els fils existeixen per raons quantitatives que hem mesurat: crear-ne un costa 22 µs davant dels 180 µs d'un procés, canviar entre fils costa 1,2 µs davant de 3,5 µs perquè no cal recarregar %cr3 ni invalidar el TLB, i compartir 1 MB entre fils costa zero davant dels 180 µs de copiar-lo entre processos. Dels tres models d'implementació, N:1 va morir per bloquejar tot el procés a cada crida bloquejant, M:N per la seva complexitat —encara que ha tornat als runtimes de Go i Java—, i Linux va triar 1:1 amb NPTL.

I la revelació de la lliçó: Linux no implementa fils. Implementa clone(), i un fil és una tasca creada amb CLONE_VM|CLONE_THREAD|CLONE_FILES|... mentre que un procés és una tasca creada sense aquests flags. D'aquí que el planificador reparteixi CPU entre fils i no entre processos, que la frontera sigui un continu que els contenidors explotaran al mòdul 6, i que cada fil tingui el seu directori a /proc/<pid>/task/ visible amb ps -eLf.

En C, pthread_create/pthread_join i el patró que importa: els quatre fils de l'ingestor assoleixen 3,49× d'acceleració sense ni una sola primitiva de sincronització, perquè cadascun treballa sobre un rang disjunt de l'array de Lectura i escriu el seu resultat a la seva pròpia estructura. Partir les dades guanya a protegir les dades. En Python, el GIL fa que 4 fils amb càrrega de CPU triguin 5,88 s davant d'1,42 s d'un de sol —pitjor, no igual— mentre que amb càrrega d'E/S escalen perfectament; per calcular, multiprocessing dona 3,8×. Els grups de fils eviten el cost de creació repetit i l'explosió de fils, i el dimensionament surt de nuclis × (1 + espera/cpu). Entre les tres arquitectures de servidor, meteo-api fa servir fils i l'ingestor fa servir epoll, cadascun pel seu perfil de càrrega. I la terminació es fa de manera cooperativa, mai amb pthread_cancel, i mai amb exit() des d'un treballador.

Però en tota la lliçó hem fet trampa. Els quatre fils de l'ingestor no compartien res escrit, i per això funcionaven. Tan bon punt calgui compartir de debò, i sobretot tan bon punt els fluxos siguin processos separats —com ingestor, agregador i meteo-api, que no comparteixen espai d'adreces—, cal un mecanisme explícit perquè es passin dades. Com li envia l'ingestor un lot de lectures a l'agregador, si són processos diferents amb memòries separades? Què és realment una canonada per dins? I com se li diu a un procés «recarrega la teva configuració» sense aturar-lo?

És el torn de Comunicació entre Processos (IPC).