I thread hanno un heap distinto?

Question

Per quanto ne so, ogni thread ottiene uno stack distinto quando il thread viene creato dal sistema operativo. Mi chiedo se ogni thread ha un heap distinto anche da solo?

Answer 1

No. Tutti i thread condividono un heap comune.

Ogni thread has a private stack, da cui è possibile aggiungere e rimuovere rapidamente elementi. Ciò rende la memoria basata sullo stack veloce, ma se si utilizza troppa memoria dello stack, come accade nella ricorsione infinita, si otterrà un overflow dello stack.

Poiché tutti i thread condividono lo stesso heap, l'accesso all'allocatore/deallocator deve essere sincronizzato. Esistono vari metodi e librerie per evitare allocator contention.

Alcuni linguaggi consentono di creare pool privati ​​di memoria o singoli heap, che è possibile assegnare a un singolo thread.

Answer 2

In genere, i thread condividono l'heap e altre risorse, tuttavia esistono costruzioni simili a thread che non lo fanno. Tra queste costruzioni filiformi vi sono i processi leggeri di Erlang e i processi full-on di UNIX (creati con una chiamata a fork()). Si potrebbe anche lavorare sulla concorrenza multi-macchina, nel qual caso le opzioni di comunicazione inter-thread sono notevolmente più limitate.

Answer 3

Per impostazione predefinita, C ha un solo heap.

Detto questo, alcuni allocatori che sono a conoscenza del thread ripartiranno l'heap in modo che ogni thread abbia la propria area da cui allocare. L'idea è che questo dovrebbe migliorare l'heap.

Un esempio di tale heap è Hoard.

Answer 4

Ogni thread ha il proprio stack e stack di chiamate.

Ogni thread condivide lo stesso heap.

Answer 5

In generale, tutti i thread utilizzano lo stesso spazio di indirizzi e, di conseguenza, hanno in genere un solo heap.

Tuttavia, può essere un po 'più complicato. Si potrebbe cercare Thread Local Storage (TLS), ma memorizza solo valori singoli.

specifiche di Windows: TLS-spazio può essere assegnato utilizzando TlsAlloc e liberato mediante TlsFree (panoramica here). Di nuovo, non è un heap, solo DWORD.

Stranamente, Windows supporta più Heaps per processo. Uno può memorizzare l'handle di Heap in TLS. Allora avresti qualcosa come un "Thread-Local Heap". Tuttavia, solo l'handle non è noto agli altri thread, ma possono ancora accedere alla sua memoria utilizzando i puntatori poiché è ancora lo stesso spazio di indirizzamento.

EDIT: Alcuni allocatori memoria (specificamente jemalloc su FreeBSD) usa TLS per assegnare "arene" per filettature. Questo viene fatto per ottimizzare l'allocazione per più core riducendo l'overhead di sincronizzazione.

Answer 6

Dipende dal sistema operativo. Il runtime c standard su Windows e Unix utilizza un heap condiviso su thread. Questo significa bloccare ogni malloc/libero.

Su Symbian, ad esempio, ogni thread viene fornito con il proprio heap, sebbene i thread possano condividere i puntatori ai dati allocati in qualsiasi heap. A mio avviso, il design di Symbian è migliore in quanto non solo elimina la necessità di bloccare durante alloc/free, ma incoraggia anche le specifiche pulite della proprietà dei dati tra i thread. Anche in questo caso, quando un thread muore, prende tutti gli oggetti che lo hanno allocato insieme ad esso - cioè non può perdere oggetti che ha allocato, che è una proprietà importante da avere nei dispositivi mobili con memoria vincolata.

Erlang segue anche un progetto simile in cui un "processo" funge da unità di garbage collection. Tutti i dati vengono comunicati tra processi mediante copia, ad eccezione dei blob binari che sono conteggiati con riferimento (credo).

Answer 7

Dipende da cosa intendi esattamente quando dici "mucchio".

Tutti i thread condividono lo spazio indirizzo, quindi gli oggetti allocati su heap sono accessibili da tutti i thread. Tecnicamente, anche gli stack sono condivisi in questo senso, ad esempio niente impedisce di accedere allo stack di altri thread (anche se non avrebbe quasi mai senso farlo).

D'altra parte, ci sono strutture heap utilizzate per allocare memoria. È qui che viene eseguita tutta la contabilità per l'allocazione della memoria heap. Queste strutture sono organizzate in modo sofisticato per ridurre al minimo la contesa tra i thread, quindi alcuni thread potrebbero condividere una struttura heap (un'arena) e alcuni potrebbero utilizzare arene distinte.
Vedere thread per un'eccellente spiegazione dei dettagli: How does malloc work in a multithreaded environment?

Answer 8

On sistema operativo, FreeRTOS compiti (fili) condividono lo stesso mucchio ma ognuno di essi ha un proprio stack. Questo è molto utile quando si ha a che fare con architetture a bassa potenza di RAM bassa, perché è possibile accedere/condividere lo stesso pool di memoria da più thread, ma questo ha un piccolo problema, lo sviluppatore deve tenere presente che un meccanismo per sincronizzare malloc è necessario e gratuito, ecco perché è necessario utilizzare un qualche tipo di sincronizzazione/blocco del processo quando si assegna o si libera memoria nell'heap, ad esempio un semaforo o un mutex.