Perché la libreria glibc e pthread hanno entrambe le stesse API?

Question

Perché la libreria glibc e pthread hanno entrambe le stesse API? Ecco l'istantanea

ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libc.so.6 |grep pthread_cond_signal 
000f8360 g DF .text 00000039 GLIBC_2.3.2 pthread_cond_signal 
0012b940 g DF .text 00000039 (GLIBC_2.0) pthread_cond_signal 

ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libpthread.so.0 |grep pthread_cond_signal 
0000b350 g DF .text 0000007c (GLIBC_2.0) pthread_cond_signal 
0000af90 g DF .text 000000fc GLIBC_2.3.2 pthread_cond_signal 

Answer 1

libpthread.so fa parte di glibc troppo, ed entrambi contengono (identici) definizioni di alcuni simboli.

Se cercate pthread_create invece vedrete che è presente solo in libpthread.so - questo significa programmi devono collegarsi a libpthread.so per creare effettivamente le discussioni , ma possono utilizzare i mutex e variabili di condizione nei programmi single-threaded che solo collegamento a libc.so. Questo è utile per interprocessi mutex e interprocess per variabili di condizione che vivono nella memoria condivisa e sono usati per sincronizzare con processi separati . (correzioni grazie al commento di Zan Lynx qui sotto).

Non è un problema collegare entrambi a libpthread.so e libc.so anche se entrambi definiscono il simbolo. I linker ELF consentono a più librerie condivise di contenere le definizioni dello stesso simbolo e il linker sceglierà il primo che vede e lo userà per tutti i riferimenti a quel simbolo, questo è chiamato symbol interposition. Un'altra caratteristica che consente di definire più simboli è se una libreria contiene weak symbols che verrà sovrascritta da simboli non deboli con lo stesso nome. In questo caso le definizioni in le due librerie sono identiche, quindi non importa quale sia utilizzato libpthread.so sovrascrive quelli in libc.so. Se si utilizza LD_DEBUG e cambiare l'ordine degli argomenti al linker si dovrebbe essere in grado di vedere quale libreria il simbolo viene effettivamente trovato in.

Oltre alle due biblioteche che definiscono lo stesso simbolo, ogni libreria ha due definizioni del simbolo, con diverso symbol versions, GLIBC_2.0 e GLIBC_2.3.2. Questo controllo delle versioni dei simboli consente a più definizioni di coesistere nella stessa libreria in modo che nuove versioni migliorate della funzione vengano aggiunte alla libreria senza interrompere il codice collegato alla vecchia implementazione. Ciò consente alla stessa libreria condivisa di funzionare per applicazioni che utilizzano LinuxThreads e applicazioni che utilizzano NPTL. Il simbolo predefinito a cui un riferimento sarà associato quando si collega alla libreria è pthread_cond_signal@GLIBC_2.3.2 che corrisponde all'implementazione NPTL di quella funzione (NPTL è stato incluso per la prima volta in glibc 2.3.2). Il simbolo precedente, pthread_cond_signal@GLIBC_2.0, è la precedente implementazione di LinuxThreads che era l'impostazione predefinita prima della fornitura di NPTL. Le applicazioni collegate a versioni precedenti (pre-2.3.2) di glibc saranno associate a pthread_cond_signal@GLIBC_2.0 e utilizzeranno tale simbolo.