Gerenciado e Threading no Microsoft Windows
Gerenciamento de todos os threads é feito por meio de Thread classe, incluindo os threads criados pelo common language runtime e aqueles criados fora o tempo de execução que insira o ambiente gerenciado para executar o código. O tempo de execução monitora todos os threads em seu processo nunca tiverem executado o código dentro do ambiente de execução gerenciado. Ele não controla qualquer outros segmentos. Segmentos podem inserir o ambiente de execução gerenciado por meio de interoperabilidade COM (porque o runtime expõe os objetos gerenciados como objetos COM o mundo não gerenciado), o COM DllGetClassObject() função e a invocação de plataforma.
Quando um thread não gerenciado insere o tempo de execução por meio de, por exemplo, um COM callable wrapper, o sistema verifica o armazenamento local de segmento dessa thread para procurar gerenciadas interna segmento objeto. Se for encontrado, o runtime já está ciente deste segmento. Se não encontrar um, no entanto, o runtime cria uma nova segmento de objeto e o instala no armazenamento local de segmento do thread.
No gerenciados de threading, Thread.GetHashCode é a identificação de estável thread gerenciado. Tempo de vida do seu segmento, ele será colide com o valor de outro segmento, independentemente do domínio do aplicativo do qual você obter esse valor.
Observação
Um sistema operacional ThreadId não tem nenhuma relação fixa para um segmento gerenciado, porque um host não gerenciado pode controlar a relação entre os threads gerenciados e não gerenciados.Especificamente, um host sofisticado pode usar a API de fibra para agendar muitos threads gerenciados contra o mesmo thread do sistema operacional ou mover um thread gerenciado entre threads do sistema operacional diferente.
Mapeamento de Threading do Win32 para Threading gerenciado
A tabela a seguir mapeia os elementos de threads do Win32 para seu equivalente em tempo de execução aproximado. Observe que esse mapeamento não representa funcionalidades idênticas. Por exemplo, TerminateThread não executar Finalmente cláusulas ou liberar recursos e não pode ser evitada. No entanto, Thread.Abort executa todo o código de reversão, recupera todos os recursos e pode ser negado usando ResetAbort. Certifique-se de ler a documentação atentamente antes de fazer suposições sobre a funcionalidade.
No Win32 |
No common language runtime |
|---|---|
CreateThread |
Combinação de de segmento e ThreadStart |
TerminateThread |
|
SuspendThread |
|
ResumeThread |
|
Suspensão |
|
WaitForSingleObject no identificador de segmento |
|
ExitThread |
Não há equivalente |
GetCurrentThread |
|
SetThreadPriority |
|
Não há equivalente |
|
Não há equivalente |
|
Fechar para CoInitializeEx (OLE32.DLL) |
Threads gerenciados e Apartments COM
Um segmento gerenciado pode ser marcado para indicar que hospedará um apartamento single-threaded ou multithread. O GetApartmentState, SetApartmentState, e TrySetApartmentState métodos para a Thread classe retornar e atribuir o estado apartment de um segmento. Se o estado não tiver sido definido, GetApartmentState retorna ApartmentState.Unknown.
Observação
No.NET Framework versões 1.0 e 1.1, o ApartmentState propriedade é usada para obter e definir o estado de apartamento.
A propriedade pode ser definida somente quando o thread está na ThreadState.Unstarted estado; pode ser definido apenas uma vez para um segmento.
Se o estado de apartamento não for definido antes que o segmento é iniciado, o segmento é inicializado como um MTA (multithreaded apartment). O thread do finalizador e todos os threads controlados por ThreadPool são MTA.
.gif "Observação importante") Importante |
|---|
Código de inicialização do aplicativo, a única maneira de controlar o estado do apartamento é aplicar o MTAThreadAttribute ou STAThreadAttribute para a entrada de ponto de procedimento.No.NET Framework versões 1.0 e 1.1, o ApartmentState propriedade pode ser definida como a primeira linha de código.Isso não é permitido o.NET Framework versão 2.0. |
Os objetos gerenciados são expostos a COM se comportam como se eles tinham agregados de empacotamento de segmentação livre. Em outras palavras, eles podem ser chamados de qualquer apartment COM uma maneira de segmentação livre. Os únicos objetos gerenciados que não exibem este comportamento de segmentação livre são aqueles objetos que derivam de ServicedComponent.
No mundo gerenciado, não há nenhum suporte para o SynchronizationAttribute , a menos que você usar contextos e instâncias gerenciados vinculados a contexto. Se você estiver usando EnterpriseServices, e seu objeto deve derivar de ServicedComponent (que propriamente dito é derivado de ContextBoundObject).
Quando o código gerenciado chama objetos COM, sempre segue regras COM. Em outras palavras, ele chama por meio de proxies de apartment COM e wrappers de contexto de COM+ 1.0 como determinado pela OLE32.
Problemas de bloqueio
Se o segmento faz uma chamada não gerenciada no sistema operacional que bloqueou o segmento de código não gerenciado, o runtime não terão o controle dele para Thread.Interrupt ou Thread.Abort. No caso de Thread.Abort, o runtime marca o segmento para Anular e assume o controle dele quando ele reentrada código gerenciado. É preferível que você use um bloqueio gerenciado em vez de bloqueio não gerenciado. WaitHandle.WaitOne,WaitHandle.WaitAny, WaitHandle.WaitAll, Monitor.Enter, Monitor.TryEnter, Thread.Join, GC.WaitForPendingFinalizers, and so on are all responsive to Thread.Interrupt and to Thread.Abort. Além disso, se o thread está em um single-threaded apartment, todas essas operações de bloqueio gerenciadas serão corretamente bomba mensagens em seu compartimento enquanto o thread estiver bloqueado.