Problemas com Threads MO801/MC972. Muitas threads Se algumas threads ajudam o programa, muitas threads devem ajudar mais –Certo? O overhead de escalonamento.

Apresentação em tema: "Problemas com Threads MO801/MC972. Muitas threads Se algumas threads ajudam o programa, muitas threads devem ajudar mais –Certo? O overhead de escalonamento."— Transcrição da apresentação:

1 Problemas com Threads MO801/MC972

2 Muitas threads Se algumas threads ajudam o programa, muitas threads devem ajudar mais –Certo? O overhead de escalonamento de escalonamento começa a pesar –Tempo para salvar e restaurar o contexto –Concorrência pela cache –Concorrência pela memória virtual –Concorrência por recursos escassos (lock por exemplo)

3 Tempo para salvar e restaurar o contexto Em geral é bem pequeno Otimizado pelos sistemas operacionais que usam time slice de um tamanho razoável O que acontece quando, sucessivamente, threads são ativadas e bloqueiam logo em seguida?

4 Concorrência pela cache Assuma –Multithread com conjuntos de dados separados –Mais threads que o número físico de processadores A concorrência fará com que as threads sejam suspensas Os mecanismos de substituição das caches trocam os dados mais antigos –Que são exatamente os dados das threads antigas Acesso à memória é caro, não tirar proveito da cache também é caro

5 Concorrência pela memória virtual Mesmo problema da cache, em outro nível Pode não haver memória física o suficiente Pode não haver memória virtual o suficiente!

6 Concorrências por recursos escassos Locks geram serialização de acesso Muitas threads esperando por um mesmo lock –Se a thread que possui o lock encerrar seu time slot, todas as outras terão que esperar mais ainda

7 Sugestões Trabalhar com número de threads relacionado com o número físico de processadores –OpenMP Usar pool de threads, evitando o overhead de criar/matar threads –Existem bibliotecas para isso Criar seu próprio gerenciador de tarefas, usando work stealing (uma thread rouba trabalho da outra)

8 Onde e como podem acontecer condições de corrida Thread 1 x += 1 a[i] += 1 *p += 1 Foo(1) add [edi], 1 Thread 2 x += 2 a[j] += 2 *q += 2 Foo(2) add [edi], 2

9 Como corrigir? Inserir locks é uma alternativa Onde inserir? –Baixo nível Nos exemplos anteriores, locks poderiam ser colocados Como alternativas, poderiam ser usadas instruções atômicas –Alto nível Provavelmente também será necessário utilizar locks num nível de abstração superior Locks redundantes geram problemas de desempenho –Em geral, as implementações de locks são otimizadas para o caso mais comum (isso é bom)

10 Deadlocks Ocorrem quando –Há acesso exclusivo a um recurso –Uma thread pode possuir um recurso e solicitar outro –Nenhuma thread desiste do seu recurso –Existe um ciclo de threads tentando obter os recursos umas das outras Pode ser removido resolvendo uma das situações acima

11 Evitando deadlocks Replicação dos dados –Melhora também a escalabilidade –Nem sempre é possível Ordenação dos locks –Todas as threads solicitam os locks na mesma ordem –Qualquer ordem é suficiente Lexicográfica no nome do lock Ordem de endereço da memória do lock A thread desiste dos locks que possui se não conseguir os que necessita

12 Ordenação de Locks void AcquireTwoLocksViaOrdering( Lock& x, Lock& y) { if (&x<&y) { aquire x aquire y } else { aquire y aquire x }

13 Desistir de lock e tentar novamente void AcquireTwoLocksViaBackoff( Lock& x, Lock& y) { for (int t=1; ; t*=2) { acquire x try to acquire y if (y was acquired) break; release x wait for random amount of time between 0 and t }

14 Inversão de prioridades Threads de alta prioridade podem ser suspensas ao aguardarem por recursos bloqueados por threads de baixa prioridade –Nesse intervalo de tempo, threads de prioridade abaixo da primeira ficam executando Aconteceu na missão Mars Pathfinder da NASA

15 Soluções Herança de prioridade –Quando uma thread aguarda um lock, a thread que possui esse lock pode ter sua prioridade elevada para o mesmo nível da primeira –Somente locks que possuem inversão de prioridade cairão no caso acima –Método lazy

16 Soluções Teto de prioridade –Para cada lock é definido o valor máximo de prioridade que uma thread que o obtém pode ter –Qualquer thread que obtém o lock é elevada a esse nível de prioridade –Esse método eleva mais prioridades que o necessário

17 Particionamento de lock Ao invés de um único lock para um grande recurso, é interessante dividí-lo em partes e utilzar locks separados Use uma função de hash com o parâmetro para indicar que lock obter –Ex.: Um vetor de 10.000 elementos com 20 locks apenas

18 Compartilhamento falso em caches A menor unidade de compartilhamento de dados entre processadores é uma linha de cache Ao invés de implementar concorrência em nível de palavras, procure aumentar o tamanho do elemento –Tamanho do vetor –Tamanho da estrutura