Pelo que eu sei, cada thread obtém uma pilha distinta quando o thread é criado pelo sistema operacional. Eu me pergunto se cada thread tem um heap distinto para si também?
sim, windows e linux, biblioteca c
Pelo que eu sei, cada thread obtém uma pilha distinta quando o thread é criado pelo sistema operacional. Eu me pergunto se cada thread tem um heap distinto para si também?
Respostas:
Não. Todos os threads compartilham um heap comum.
Cada thread tem uma pilha privada , da qual pode adicionar e remover itens rapidamente. Isso torna a memória baseada em pilha rápida, mas se você usar muita memória de pilha, como ocorre na recursão infinita, você obterá um estouro de pilha.
Como todos os threads compartilham o mesmo heap, o acesso ao alocador / desalocador deve ser sincronizado. Existem vários métodos e bibliotecas para evitar a contenção do alocador .
Alguns idiomas permitem que você crie pools privados de memória, ou heaps individuais, que você pode atribuir a um único thread.
you will get a stack overflow.Um estouro de pilha em Stack Overflow!
Por padrão, C tem apenas um único heap.
Dito isso, alguns alocadores com reconhecimento de thread particionarão o heap de modo que cada thread tenha sua própria área para alocar. A ideia é que isso deve melhorar a escala do heap.
Um exemplo de tal pilha é Hoard .
Depende do SO. O tempo de execução c padrão em windows e unices usa um heap compartilhado entre threads. Isso significa bloquear todos os malloc / free.
No Symbian, por exemplo, cada thread vem com seu próprio heap, embora os threads possam compartilhar ponteiros para dados alocados em qualquer heap. O design do Symbian é melhor na minha opinião, uma vez que não apenas elimina a necessidade de bloqueio durante a alocação / liberação, mas também incentiva a especificação limpa de propriedade de dados entre threads. Também nesse caso, quando um thread morre, ele leva todos os objetos alocados junto com ele - ou seja, ele não pode vazar objetos que alocou, o que é uma propriedade importante em dispositivos móveis com memória restrita.
Erlang também segue um design semelhante, onde um "processo" atua como uma unidade de coleta de lixo. Todos os dados são comunicados entre processos por cópia, exceto para blobs binários que são contados por referência (eu acho).
Depende do que exatamente você quer dizer com "amontoar".
Todos os threads compartilham o espaço de endereço, portanto, os objetos alocados por heap são acessíveis de todos os threads. Tecnicamente, as pilhas também são compartilhadas neste sentido, ou seja, nada impede que você acesse a pilha de outra thread (embora isso quase nunca faça sentido).
Por outro lado, existem estruturas de heap usadas para alocar memória. É aí que toda a contabilidade para alocação de memória heap é feita. Essas estruturas são sofisticadamente organizadas para minimizar a contenção entre os threads - portanto, alguns threads podem compartilhar uma estrutura de heap (uma arena) e alguns podem usar arenas distintas.
Consulte o thread a seguir para obter uma explicação excelente dos detalhes: Como o malloc funciona em um ambiente multithread?
Normalmente, os threads compartilham o heap e outros recursos, no entanto, há construções semelhantes a threads que não compartilham. Entre essas construções semelhantes a thread estão os processos leves de Erlang e os processos full-on do UNIX (criados com uma chamada para fork()). Você também pode estar trabalhando em simultaneidade multi-máquina; nesse caso, suas opções de comunicação entre threads são consideravelmente mais limitadas.
De um modo geral, todos os threads usam o mesmo espaço de endereço e, portanto, geralmente têm apenas um heap.
No entanto, pode ser um pouco mais complicado. Você pode estar procurando por Thread Local Storage (TLS), mas ele armazena apenas valores únicos.
Específico do Windows: o espaço TLS pode ser alocado usando TlsAlloc e liberado usando TlsFree (Visão geral aqui ). Novamente, não é um heap, apenas DWORDs.
Estranhamente, o Windows oferece suporte a vários Heaps por processo. Pode-se armazenar o identificador do Heap em TLS. Então você teria algo como um "Thread-Local Heap". No entanto, apenas o identificador não é conhecido pelas outras threads, elas ainda podem acessar sua memória usando ponteiros, pois ainda é o mesmo espaço de endereço.
EDITAR : Alguns alocadores de memória (especificamente o jemalloc no FreeBSD) usam TLS para atribuir "arenas" às threads. Isso é feito para otimizar a alocação de vários núcleos, reduzindo a sobrecarga de sincronização.
No sistema operacional FreeRTOS, as tarefas (threads) compartilham a mesma pilha, mas cada uma delas tem sua própria pilha. Isso é muito útil ao lidar com arquiteturas de RAM de baixo consumo de energia, porque o mesmo pool de memória pode ser acessado / compartilhado por vários threads, mas isso vem com um pequeno problema, o desenvolvedor precisa ter em mente que um mecanismo para sincronizar malloc e free é necessário, por isso é necessário usar algum tipo de sincronização / bloqueio de processo ao alocar ou liberar memória no heap, por exemplo, um semáforo ou um mutex.