Partilhar via


Escrevendo um programa Win32 multithread

Quando você escreve um programa com vários segmentos, você deve coordenada seu comportamento e uso dos recursos do programa.Você também deve certificar-se de que cada thread recebe sua própria pilha.

Compartilhamento de recursos comuns entre threads

Observação:

Para obter uma discussão semelhante de p MFC Consulte oint do modo de exibição Multithreading: Dicas de Programação e Multithreading: Quando usar as classes de sincronização.

Cada thread tem sua própria pilha e sua própria cópia dos registros de CPU.Outros recursos, sistema autônomo arquivos, dados estático e memória heap, são compartilhados por todos sistema autônomo threads do processo.Segmentos utiliza esses recursos comuns devem ser sincronizados.Win32 fornece várias maneiras de recursos, incluindo seções críticas, semáforos, eventos e exclusões mútuas.

Quando vários segmentos estão acessando dados estático, o programa deve fornecer para conflitos de recursos possível.Considere a possibilidade de um programa em que um thread atualiza uma estrutura de dados estático contendo x,y coordenadas para itens a serem exibidos por outro thread.Se o segmento de atualização altera o x coordenada e admitir preempção antes que ele possa alterar o y coordenadas, o thread de exibição pode ser agendado antes do y coordenada é atualizada.O item será exibido no local errado.Você pode evitar esse problema usando semáforos para controlar o acesso à estrutura.

Um mutex (forma abreviada de mutual ex conclusão) é uma forma de comunicação entre segmentos ou processos que estão execução assíncrona da outra.Essa comunicação é normalmente usada para coordenada as atividades de vários segmentos ou processos, normalmente, controlando acesso a um recurso compartilhado, bloqueio e desbloqueio do recurso.Para resolver este x,y atualização coordenada problema, o segmento de atualização define um mutex indicando que a estrutura de dados está em uso antes de executar a atualização.Ele desmarcar o mutex após o tinham processamento de ambas as coordenadas.O thread de exibição deve aguardar o mutex seja desmarcar antes de atualizar a exibição.Esse processo de esperando um mutex costuma ser chamado porque o processo está bloqueado e não pode continuar até que o mutex limpa o bloqueio em um mutex.

O programa Bounce.c mostrado na Programa de exemplo com vários threads C usa um mutex nomeado ScreenMutex para coordenar as atualizações de tela. Sempre que um dos threads exibição está pronto para gravar na tela, ele chama WaitForSingleObject com a alça de ScreenMutex e constante INFINITO para indicar que o WaitForSingleObject telefonar deve bloquear no mutex e não o time limite.If ScreenMutex é claro, a função espera define o mutex de modo que outros segmentos não podem interferir com a exibição e continuará executando o thread. Caso contrário, o thread bloqueia até que o mutex limpa.Quando o thread conclui a atualização de vídeo, ele libera o mutex chamando ReleaseMutex.

Exibe a tela e dados estático são apenas dois dos recursos que exigem gerenciamento cuidadoso.Por exemplo, seu programa pode ter vários segmentos acessando o mesmo arquivo.Porque outro thread pode ter sido movido o ponteiro do arquivo, cada thread deverá reiniciar o ponteiro do arquivo antes de ler ou gravar.Além disso, cada thread deve certificar-se de que ele não admitir preempção entre o momento em que ele posiciona o ponteiro e o time que acessa o arquivo.Esses segmentos devem usar um sinal para coordenar o acesso ao arquivo por colchetes cada acesso a arquivos com WaitForSingleObject and ReleaseMutex chamadas.O exemplo de código a seguir ilustra essa técnica:

HANDLE    hIOMutex= CreateMutex (NULL, FALSE, NULL);

WaitForSingleObject( hIOMutex, INFINITE );
fseek( fp, desired_position, 0L );
fwrite( data, sizeof( data ), 1, fp );
ReleaseMutex( hIOMutex);

Pilhas de thread

Todo espaço de pilha padrão do aplicativo está alocado para o primeiro thread de execução, que é conhecido sistema autônomo o thread 1.sistema autônomo resultado, você deve especificar a quantidade de memória para alocar para uma pilha separada para cada adicionais thread precisa de seu programa.O sistema operacional aloca espaço de pilha adicionais para o thread, se necessário, mas você deve especificar um valor padrão.

O primeiro argumento no _beginthread telefonar é um ponteiro para o BounceProc função, que executa os threads.O segundo argumento especifica o dimensionar de pilha padrão para o thread.O último argumento é um número de ID que é passado para BounceProc.BounceProc usa o número de ID para propagar o gerador de números aleatórios e para selecionar o atributo de cor thread's e exibir o caractere.

Segmentos que fazem chamadas para a biblioteca de time de execução C ou para a API do Win32 devem permitir que o espaço de pilha suficiente para a biblioteca e eles chamam funções da API.O C printf função requer mais de 500 bytes de espaço de pilha, e você deve ter 2 K de espaço de pilha disponível quando chamando rotinas Win32 API.

sistema autônomo cada thread tem sua própria pilha, você pode evitar possíveis colisões sobre itens de dados usando sistema autônomo dados estático pouco possível.Design de seu programa para usar variáveis de pilha automático para todos os dados que podem ser privados para um segmento.As variáveis global somente no programa Bounce.c são mutexes ou variáveis que nunca é alterado depois que eles são inicializados.

Win32 também fornece armazenamento thread local (TLS) para armazenar dados por thread.Para obter mais informações, consulte Local thread Storage (TLS).

Consulte também

Conceitos

Multithreading com C e Win32