Começando Concorrente: Uma Introdução Gentil à Programação Concorrente

A ideia de dividir uma tarefa em subtarefas menores é natural. Imagine que você está planejando um jantar. Você precisa comprar suprimentos, preparar o jantar, limpar a casa e arrumar a mesa. Se quatro de vocês estivessem planejando a festa, cada um poderia realizar uma atividade separada. Os preparativos poderiam ser muito mais rápidos do que se uma única pessoa estivesse fazendo o trabalho, mas a coordenação ainda é importante. Talvez a pessoa que estiver preparando o jantar não possa terminar até que certos suprimentos sejam comprados.

A decomposição de tarefas geralmente é mais fácil do que a decomposição de domínios porque muitas tarefas têm divisões naturais. Infelizmente, essa nem sempre é uma maneira eficaz de usar vários núcleos em um computador. Se uma tarefa for concluída muito antes das outras, um núcleo poderá ficar ocioso.

Os dois exemplos a seguir mostram ilustrações simples do processo de divisão de uma tarefa em subtarefas menores no contexto da programação multicore.

Esses exemplos ilustram como uma tarefa pode ser dividida em duas ou mais subtarefas executadas por diferentes núcleos de um processador. Usamos um processador dual-core em nossos exemplos, mas as mesmas ideias podem ser expandidas para um número maior de núcleos.

Em um programa de computador, cada tarefa executa operações em dados. Esses dados são chamados de domínio dessa tarefa. Na decomposição do domínio, os dados são divididos em partes menores, em que cada parte é atribuída a um núcleo diferente, em vez de dividir uma tarefa em subtarefas. Assim, cada núcleo executa a mesma tarefa, mas em dados diferentes.

No exemplo do jantar, poderíamos ter usado a decomposição de domínio em vez de (ou além de) decomposição de tarefa. Se quiser cozinhar uma grande quantidade de purê de batatas, você mesmo pode descascar 24 batatas. Entretanto, se houver quatro pessoas (e cada uma delas tiver um descascador de batatas), cada pessoa precisará descascar apenas 6 batatas.

A estratégia de decomposição de domínio é muito útil e é um dos principais focos da simultaneidade neste livro. Os problemas da computação moderna geralmente usam dados maciços, que incluem milhões de valores ou milhares de registros de bancos de dados. Escrever programas que possam dividir os dados de modo que vários núcleos possam processar seções menores pode acelerar muito o tempo necessário para concluir o cálculo.

De certa forma, a decomposição de domínios pode ser mais difícil do que a decomposição de tarefas. Os dados devem ser divididos de maneira uniforme e justa. Depois que cada seção de dados tiver sido processada, os resultados deverão ser combinados. Empresas como o Google, que processam grandes quantidades de informações, desenvolveram uma terminologia para descrever esse processo. Dividir os dados e atribuí-los aos funcionários é chamado de etapa do mapa (map). A combinação das respostas parciais na resposta final é chamada de etapa de redução (reduce).

Ilustramos a estratégia de decomposição de domínio nos dois exemplos a seguir.

É responsabilidade do programador dividir sua solução em uma série de tarefas e subtarefas que serão executadas em um ou mais núcleos de um processador. Nas seções anteriores, descrevemos programas concorrentes como se tarefas específicas pudessem ser atribuídas a núcleos específicos, mas o Java não fornece uma maneira direta de fazer isso.

Em vez disso, um programador Java deve agrupar um conjunto de tarefas e subtarefas em uma thread. Uma thread é muito parecido com um programa sequencial. De fato, todos os programas sequenciais são compostos de uma única thread. Uma thread é um segmento de execução de código que percorre suas instruções passo a passo. Cada thread pode ser executado de forma independente. Se você tiver um processador de núcleo único apenas uma thread pode ser executada por vez, e todas as threads se revezarão. Se você tiver um processador com vários núcleos, tantas threads quantos forem os núcleos núcleos podem ser executados ao mesmo tempo. Não é possível escolher em qual núcleo uma determinada thread será executada. Na maioria dos casos, você não conseguirá nem mesmo saber qual núcleo uma determinada thread está usando.

Ele tem o cuidado de empacotar o conjunto certo de tarefas em uma única thread de execução. Lembre-se dos exemplos anteriores de programação concorrente neste capítulo.

Considere a possibilidade de dividir as tarefas em Exemplo 13.1 em duas threads. As tarefas B e C podem ser agrupadas na thread 1, e a tarefa D pode ser empacotada na thread 2.Essa divisão é mostrada em Figura 13.5(a).

As tarefas para avaliar diferentes subexpressões em Exemplo 13.2 também podem ser divididas em duas threads, conforme mostrado em Figura 13.5 (b). Em muitos problemas, há várias maneiras razoáveis de dividir um conjunto de subtarefas em threads.

Observe que essas figuras são exatamente iguais às figuras anteriores, exceto que as tarefas são agrupadas como threads em vez de núcleos. Esse agrupamento corresponde melhor à realidade, pois podemos controlar como as tarefas são agrupadas em threads, mas não como elas são atribuídas aos núcleos.

Em ambos os exemplos, temos duas threads. É possível que alguma outra thread tenha iniciado a execução dessas threads. Todo programa Java, simultâneo ou sequencial, começa com uma thread. Vamos nos referir a essa thread como a thread main, pois ela contém o método main().

Exemplo 13.3 e Exemplo 13.4 usam várias tarefas idênticas, mas essas tarefas operam em dados diferentes. Em Exemplo 13.3, as duas tarefas podem ser atribuídas a duas threads que operam em diferentes partes da matriz de entrada. A tarefa de somar os resultados das duas threads pode ser uma thread separada ou uma subtarefa incluída em uma das outras threads. Em Exemplo 13.4, as duas tarefas podem novamente ser atribuídas a duas threads distintas que operam em diferentes partes diferentes da matriz de entrada A para gerar as partes correspondentes partes correspondentes da matriz de saída C.

Pode haver muitas maneiras de empacotar tarefas em threads. Também pode haver muitas maneiras de decompor os dados em pedaços menores. As melhores maneiras de executar essas subdivisões de tarefas ou dados dependem do problema em questão e da arquitetura do processador em que o programa será executado.

Os dois paradigmas mais importantes da programação concorrente são a passagem de mensagens e os sistemas de memória compartilhada. Cada paradigma lida com a comunicação entre as várias unidades de código executadas em paralelo de uma maneira diferente. Os sistemas de passagem de mensagens, como o MPI (Message Passing Interface), abordam esse problema enviando mensagens entre unidades de código independentes, chamadas de processos. Um processo que está executando uma tarefa pode ter de esperar até receber uma mensagem de outro processo para saber como proceder. As mensagens podem ser enviadas de um único processo para outro ou transmitidas para vários. Os sistemas de passagem de mensagens são especialmente úteis quando os processadores que executam o trabalho não compartilham memória.

Por outro lado, o sistema interno de concorrência em Java usa o paradigma de memória compartilhada. compartilhada. Em Java, um programador pode criar várias threads que compartilham o mesmo espaço de memória. Cada thread é um objeto que pode executar um trabalho. Descrevemos as threads como uma como uma forma de empacotar um grupo de tarefas, e os processos são outra forma. As pessoas usam o termo processos para descrever unidades de código em execução com memória separada e threads para descrever unidades de código em execução com memória compartilhada.

Quando você aprendeu a programar pela primeira vez, um dos maiores desafios foi provavelmente aprender a resolver um problema passo a passo. Cada linha do programa tinha de ser executada uma de cada vez, de forma lógica e deterministica. Os seres humanos não pensam naturalmente dessa forma. Temos a tendência de pular de uma coisa para outra, fazendo inferências e suposições, pensando em duas coisas não relacionadas ao mesmo tempo, e assim por diante. Como você sabe agora, só é possível escrever e depurar programas por causa da maneira metódica como eles funcionam.

Você pode imaginar a execução de um programa como uma seta que aponta para uma linha de código, depois a próxima, depois a próxima e assim por diante. Podemos pensar no movimento dessa seta como a thread de execução do programa. O código faz o trabalho real, mas a seta mantém o controle de onde a execução do programa está no momento. O código pode mover a seta para frente, pode fazer aritmética básica, pode decidir entre escolhas com instruções pode fazer coisas repetidamente com loops, pode pular para um método e depois voltar. Uma única thread de execução pode fazer todas essas coisas, mas sua seta não pode estar em dois lugares ao mesmo tempo. Ela não pode dividir dois números em uma parte do programa e avaliar uma declaração if em outra. No entanto, há uma maneira de dividir essa thread de execução de modo que duas ou mais threads estejam executando partes diferentes do programa, e a próxima seção mostrará como isso é feito em Java.

O Java, como muitas linguagens de programação, inclui os recursos necessários para para empacotar tarefas e subtarefas em threads. A classe Thread e suas subclasses fornecem as ferramentas para criar e gerenciar threads. Por exemplo, a definição de classe a seguir permite que objetos do tipo ThreadedTask sejam criados. Esse objeto pode ser executado como uma thread separada.

O construtor é escrito como qualquer outro construtor, mas há um método especial run() em Thread que pode ser substituído por qualquer uma das suas subclasses. Esse método é o ponto de partida para a thread de execução associada a uma instância da classe. A maioria dos aplicativos Java começa com uma única thread principal que é iniciado em um método main(). As threads adicionais devem começar em algum lugar, e esse lugar é o método run(). Um aplicativo Java continuará a ser executado enquanto houver pelo menos uma thread ativa. O exemplo a seguir mostra duas threads, cada uma avaliando uma subexpressão separada, como em Figura 13.5(b).

Criar um objeto a partir de uma subclasse Thread é o mesmo que criar qualquer outro objeto em Java. Por exemplo, podemos instanciar a classe Thread1 acima para criar um objeto chamado thread1.

O uso da palavra-chave new para invocar o construtor cria um objeto Thread1, mas não começa a executá-lo como uma nova thread. Como em todas as outras classes, o construtor inicializa os valores dentro do novo objeto objeto. Uma subclasse de Thread pode ter muitos construtores diferentes com qualquer parâmetros que seu projetista considere apropriados.

Para iniciar a execução do objeto thread, seu método start() deve ser chamado. Por exemplo, o objeto thread1 criado acima pode ser iniciado da seguinte forma.

Uma vez iniciado, uma thread é executada de forma independente. A chamada do método start() chama automaticamente o método run() do objeto nos bastidores. Quando uma thread precisa compartilhar dados com outra thread, ela pode ter que esperar.

Muitas vezes, alguma thread, principal ou não, precisa esperar por outra thread antes de prosseguir com sua execução. O método join() é usado para esperar que uma thread termine a execução. Por exemplo, qualquer thread que executar o código a seguir aguardará a conclusão da thread1.

A chamada join() é uma chamada bloqueante, o que significa que o código que chama esse método aguardará até que ele retorne. Como ele pode lançar uma InterruptedException verificada enquanto o código estiver aguardando, o método join() é geralmente usado em um bloco try-catch. Podemos adicionar um bloco try-catch ao exemplo thread1 para que possamos nos recuperar de sermos interrompidos enquanto aguardamos a conclusão do thread1.

Observe que a InterruptedException é lançada porque a thread principal foi interrompida enquanto aguardava a conclusão da thread1. Se a chamada join() retornar, então thread1 deve ter terminado e informaremos o usuário. Se uma InterruptedException for lançada, alguma thread externa deve ter interrompido a thread principal, forçando-a a parar de esperar pela thread1.

In earlier versions of Java, there was a stop() method which would stop an executing thread. Although this method still exists, it’s been deprecated and shouldn’t be used because it can make a program behave in an unexpected way.

Embora seja possível criar threads em Java herdando diretamente da classe Thread diretamente, a API Java permite que o programador use uma interface em vez disso.

Como exemplo, a classe Summer pega uma matriz de valores int e os soma dentro de um determinado intervalo. Se várias instâncias dessa classe forem executadas como threads separadas, cada uma delas poderá somar diferentes partes de uma matriz.

Essa classe é muito semelhante a uma classe que herda de Thread. Imagine por um momento que o código que segue Summer é extends Thread em vez de implements Runnable. A principal coisa que uma classe derivada de Thread precisa é de um método run() sobrescrito. Como somente o método run() é importante, os projetistas do Java forneceram uma maneira de criar uma thread usando a interface Runnable. Para implementar essa interface, é necessário apenas um método public void run().

Ao criar uma nova thread, há algumas diferenças de sintaxe entre os dois estilos. A maneira conhecida de criar e executar um thread a partir de uma subclasse Thread é a seguinte.

Como o Summer não herda de Thread, ele não tem um método start(), e esse código não será compilado. Quando uma classe apenas implementa Runnable, ainda é necessário criar um objeto Thread e chamar seu método start(). Portanto, é necessária uma etapa extra.

Essa forma alternativa de implementar a interface Runnable parece mais incômoda do que herdar diretamente da Thread, já que é necessário instanciar um objeto Thread separado. Entretanto, a maioria dos desenvolvedores prefere projetar classes que implementem Runnable em vez de herdar de Thread. Por quê? O Java só permite herança única. Se sua classe implementar Runnable, ela estará livre para herdar de outra super classe com os recursos que você desejar.

Em Java, o mapeamento de uma thread dentro da JVM para uma thread no sistema operacional varia. Algumas implementações dão a cada thread Java uma thread do sistema operacional, outras colocam todas as threads Java em uma única thread do sistema operacional (com o efeito colateral de impedir a execução paralela), e algumas permitem a possibilidade de alterar qual thread do sistema operacional uma thread Java usa. Assim, o desempenho e, em alguns casos, a correção de seu programa podem variar, dependendo do sistema que você estiver executando. Esse é, mais uma vez, um daqueles momentos em que o Java é independente de plataforma…​ mas não totalmente.

Infelizmente, a situação é ainda mais complicada. Tornar as threads parte de seu programa significa que o mesmo programa pode ser executado de forma diferente no mesmo sistema. A JVM e o sistema operacional precisam cooperar para agendar as threads e ambos os programas são montanhas complexas de código que tentam equilibrar muitos fatores. Se você criar três threads, não há garantia que o primeiro será executado primeiro, o segundo segundo e o terceiro terceiro, mesmo que isso aconteça nas primeiras 10 vezes em que você executar o programa. O Exercício 13.18 mostra que o padrão de execução das threads pode variar muito.

Em todos os programas anteriores a este capítulo, a mesma sequência de entrada sempre produziria a mesma sequência de saída. Talvez o maior obstáculo criado por esse não determinismo seja o fato de os programadores terem de mudar seu paradigma consideravelmente. O processador pode alternar entre execuções de de threads a qualquer momento, mesmo no meio das operações. Todas as possíveis intercalações de execução de thread pode surgir em algum momento. A menos que você tenha certeza de que seu programa se comporta adequadamente em todos eles, talvez você nunca conseguirá depurar seu código completamente. O que é tão insidioso nos bugs não determinísticos é que eles podem ocorrer raramente e ser quase impossíveis de reproduzir. Neste capítulo, apresentamos como criar e executar threads, mas fazer com que essas threads interajam adequadamente é um problema importante que abordaremos nos capítulos seguintes.

Depois dessas terríveis palavras de advertência, gostaríamos de lembrá-lo de que o não determinismo não é em si uma coisa ruim. Muitos aplicativos com threads com muitas entradas e saídas, como os servidores de aplicação, necessariamente existem em um mundo não determinístico. Para esses programas, muitas diferentes sequências de threads em execução podem ser perfeitamente válidas. Cada programa individual pode ter uma definição diferente de correção. Por exemplo, se um servidor do mercado de ações receber duas solicitações para comprar a última ação de uma determinada empresa quase ao mesmo tempo de duas threads correspondentes a dois clientes diferentes, pode ser correto que qualquer um deles obtenha a última ação. No entanto, nunca seria correto que ambos a recebam.

Até agora, o único mecanismo que introduzimos para coordenar diferentes threads é usar o método join() para aguardar o término de uma thread. Outra técnica é polling, ou busy waiting. A ideia é continuar verificando o estado de uma thread até que ela mude.

Há vários problemas com essa abordagem. O primeiro é que ela desperdiça ciclos da CPU. Os ciclos gastos pela thread em espera continuamente poderiam ter sido usados de forma produtiva por alguma outra thread no sistema. O segundo problema é que precisamos ter certeza de que o estado da thread que estamos esperando não voltará ao estado original ou para algum outro estado. Devido à imprevisibilidade do agendamento, não há garantia de que a thread em espera lerá o estado da outra thread quando ela tiver o valor correto.

Mencionamos a votação em parte porque ela tem uma importância histórica para a programação paralela, em parte porque pode ser útil na solução de alguns problemas deste capítulo e, em parte, porque queremos que você entenda os motivos pelos quais precisamos de técnicas melhores para a comunicação entre threads.