pthread_create von pthread_detach gefolgt Ergebnisse noch in möglicherweise verloren Fehler in Valgrind

Question

ich ein Problem habe mit Valgrind mir zu sagen, ich etwas Speicher möglich verloren haben:

==23205== 544 bytes in 2 blocks are possibly lost in loss record 156 of 265 
==23205== at 0x6022879: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==23205== by 0x540E209: allocate_dtv (in /lib/ld-2.12.1.so) 
==23205== by 0x540E91D: _dl_allocate_tls (in /lib/ld-2.12.1.so) 
==23205== by 0x623068D: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.12.1.so) 
==23205== by 0x758D66: MTPCreateThreadPool (MTP.c:290) 
==23205== by 0x405787: main (MServer.c:317) 

Der Code, der diese Fäden (MTPCreateThreadPool) schafft im Grunde bekommt ein Index in einen Block wartender pthread_t-Slots und erstellt daraus einen Thread. TI wird ein Zeiger auf eine Struktur, die einen Thread-Index und ein Pthread_t hat. (Vereinfacht/hygienisiert):

for (tindex = 0; tindex < NumThreads; tindex++) 
    { 
    int rc; 
    TI = &TP->ThreadInfo[tindex]; 
    TI->ThreadID = tindex; 

    rc = pthread_create(&TI->ThreadHandle,NULL,MTPHandleRequestsLoop,TI); 
    /* check for non-success that I've omitted */ 
    pthread_detach(&TI->ThreadHandle); 
    } 

Dann haben wir eine Funktion MTPDestroyThreadPool, die durch alle Fäden Schlaufen wir geschaffen und löscht sie (da die MTPHandleRequestsLoop nicht beendet).

for (tindex = 0; tindex < NumThreads; tindex++) 
    { 
    pthread_cancel(TP->ThreadInfo[tindex].ThreadHandle); 
    } 

Ich habe an anderer Stelle lesen (andere Fragen hier auf SO einschließlich), dass ein Gewinde Abnehmen explizit diese möglicherweise verloren Fehler verhindern würde, aber es ist eindeutig nicht. Irgendwelche Gedanken?

Answer 1

Ein Grund könnte sein, dass pthread_cancel den Thread nicht wirklich abbricht - es ist nicht garantiert. Thread-Löschung ist asynchron; pthread_cancel kehrt sofort zurück, aber die Stornierung kann bis zum nächsten Löschpunkt verschoben werden. In diesem Fall sind die Threads möglicherweise noch vorhanden, wenn Valgrind Statistiken erfasst.

Answer 2

Die Thread-Implementierung von glibc löscht absichtlich Speicher. Der Speicher, der einem Thread-Kontext zugewiesen wurde, wird zwischengespeichert, um ihn beim nächsten Erstellen eines Threads wiederzuverwenden. Ich habe ein Benchmarking im Vergleich zu einer Implementierung ohne Caching durchgeführt, und es scheint, dass das Caching die ansonsten optimale Zeit für pthread_create um 50% reduziert, aber für einen Nettoverlust drastisch pthread_join verlangsamt. Natürlich ist es immer noch ein (kleiner) Gewinn, wenn das, was Sie interessieren, die Latenz der Thread-Erstellung und nicht der Durchsatz ist.

Beachten Sie auch, dass es für einen abgetrennten Thread sehr schwierig ist, seinen Kontext aufzuheben, selbst wenn er es wollte. Mit einem verknüpfbaren Thread kann der Thread, der pthread_join aufruft, den Kontext freigeben, aber ein losgelöster Thread müsste während des Intervalls zwischen dem Freigeben seines Kontexts und dem Beenden des Kontextes ohne Stack arbeiten können. Dies kann nur erreicht werden, indem dieses kleine Stück Code in reinem asm geschrieben wird.

Fragen Sie sich, wie abgelöste Threads Kontexte ohne eine ähnliche Race-Bedingung in den Cache zurückgegeben werden? Linux verfügt über eine Funktion zum Ausschließen einer int an einer bestimmten Adresse (registriert von der Userspace-Thread-Bibliothek), wenn der Thread beendet wird. So kann der Thread dem Cache sicher seinen eigenen Kontext hinzufügen, da andere Threads bis zu ihrem Abschluss immer noch einen Wert ungleich Null (normalerweise seine Thread-ID) unter dieser Adresse sehen und interpretieren, dass der Kontext noch verwendet wird.

Answer 3

Das Erstellen eines Threads, der zusammengefügt werden kann, um ihn sofort zu entfernen, ergibt für mich nicht viel Sinn. Dies erzeugt nichts als Overhead für das System.

Ich würde die Threads von Anfang an losgelöst starten, haben Sie Ihre gemeinsame ThreadInfo Datenstruktur sowieso, um Ihre Threads zu steuern.

Auch ich würde eine Flagge oder etwas ähnliches in Ihrem pro Gewindeargument ThreadInfo haben, das dem Faden sagt, um in einer kontrollierten Weise herunterzufahren.