Código 23. Exemplo de tradução de Method PON para target NOPL-Namespaces
2.3 COMUNICAÇÃO ENTRE PROCESSOS
2.3.2 Solução de Peterson
Em 1981, G. L. Peterson propôs um algoritmo para exclusão mútua que permitiu que dois ou mais processos compartilhassem recursos em suas regiões críticas sem conflitos. O respectivo algoritmo pode ser visto de maneira simplificada na Figura 8.
Figura 8. Solução de Peterson para exclusão mútua em C
Fonte: (TANENBAUM, 2010)
O algoritmo consiste em duas rotinas: enter_region e leave_region que devem ser chamadas, respectivamente, antes de entrar na região crítica e antes de sair da região crítica. Cada processo chama cada uma das rotinas de controle com seu próprio identificador de processo como parâmetro. (PETERSON, 1981). Desta forma, dois processos chamam enter_region quase simultaneamente. Ambos armazenarão seus números de processo na variável turn. O que armazenou por último é o que conta (o primeiro é sobreposto e perdido). Quando ambos os processos chegam ao comando while, o processo que armazenou por último não executa o laço e entra em sua região crítica, enquanto o outro processo executa o laço, aguardando sua vez
para entrar na região crítica que será liberada quando o processo executando na região crítica executar a instrução leave_region (TANENBAUM, 2010).
2.3.3 Semáforo
A solução de Peterson está correta no sentido de garantir o acesso exclusivo à uma região crítica. Entretanto, quando um processo aguarda para entrar em uma região crítica, fica em um laço esperando até que lhe seja permitida a entrada. Este tipo de comportamento chama-se ‘espera ociosa’ e acaba consumindo tempo de processamento (TANENBAUM, 2010).
Dijkstra (1965) propôs um algoritmo para acesso a recursos compartilhados que introduziu duas operações: down e up, generalizações para adormecer e acordar processos, respectivamente. Este algoritmo valia-se de uma variável identificada como semáforo, cujo valor seria um número inteiro. A operação down sobre um semáforo verifica se seu valor é maior que 0. Se for, decrementará o valor (isto é, gasta um sinal de acordar armazenado) e prosseguirá. Se o valor for 0, o processo será posto para dormir, sem terminar o down. Verificar o valor, alterá-lo e possivelmente colocá-lo para dormir são tarefas executadas de forma atômica9. Esta
atomicidade é absolutamente essencial para resolver problemas de sincronização e evitar condições de corrida (TANENBAUM, 2010).
2.3.4 Mutexes
Quando não é preciso usar a capacidade do semáforo de contar, lança-se mão de uma versão simplificada do algoritmo do semáforo, a este algoritmo dá-se o nome de mutex, abreviação para mutual exclusion. Mutexes são adequados apenas para gerenciar a exclusão mútua de algum recurso ou parte de código compartilhada. São fáceis de implementar e eficientes, o que os torna especialmente úteis em pacotes de
threads implementados totalmente no espaço de usuário (TANENBAUM, 2010).
9 Uma execução atômica é uma execução indivisível, ou seja, garante-se que, uma vez iniciada, nenhum outro processo pode ter acesso ao semáforo até que a operação tenha terminado ou sido bloqueada.
Mutex é uma variável que pode estar em um dos dois estados: impedido e desimpedido. Duas rotinas são usadas com mutexes: mutex_lock, quando um processo (ou thread) precisa ter acesso a uma região crítica; e mutex_unlock, quando o processo (ou thread) estiver por sair da região crítica. De certa forma, mutex é muito parecido com a solução de Peterson, porém a diferença se dá pelo seguinte aspecto: quando o processo falha em verificar a variável de trava faz uma chamada ao escalonador de forma a baixar sua prioridade, abrindo mão, assim, de processamento (TANENBAUM, 2010).
2.3.5 Mensagens assíncronas
De acordo com Tanenbaum (2010), diferentemente das soluções apresentadas até agora, que visam gerenciar e coordenar as condições de corrida a uma região crítica, a troca de mensagens assíncronas apresenta uma abordagem completamente diferente. O objetivo desta técnica é evitar regiões críticas, fazendo com que as comunicações ocorram sem qualquer tipo de compartilhamento.
A troca de mensagens consiste na implementação de duas rotinas: a rotina send para enviar uma determinada informação a um processo; e a rotina receive que trata de processar os dados recebidos pelo processo. Esta última pode ou não conhecer o processo remetente da mensagem (TANENBAUM, 2010).
Van Roy também define que troca de mensagens assíncronas é o estilo natural de um sistema distribuído, ou seja, um conjunto de computadores que podem se comunicar entre si por meio de uma rede. É natural porque reflete a estrutura do sistema e seus custos. Sistemas distribuídos estão se tornando onipresentes devido à expansão contínua da Internet. Tecnologias mais antigas para programação de sistemas distribuídos, como RPC, CORBA e RMI, são baseadas em comunicação síncrona. Novas tecnologias, como serviços da Web, são assíncronas (VAN ROY, 2004, p. 345-346).
Também importante dizer que este tipo de solução se apresenta como parte fundamental na construção de sistemas altamente confiáveis. Como as entidades de transmissão de mensagens são independentes, se uma falhar, as outras podem
continuar a executar. Em um sistema adequadamente projetado, os outros se reorganizam para continuar fornecendo um serviço.
A troca de mensagens é, portanto, um estilo de programação no qual um programa consiste em entidades independentes que interagem enviando mensagens umas às outras assincronamente, ou seja, sem esperar por uma resposta. (VAN ROY, 2004, p. 345-346). Isto posto, a troca de mensagens assíncronas é, também, a estrutura básica para sistemas multiagentes10. Um exemplar deste tipo de sistema é
o modelo de atores, o qual é apresentado em maiores detalhes na seção a seguir.
2.4 MODELO DE ATORES
Como pode ser visto na seção 2.3, foram apresentadas soluções para os problemas de comunicação entre processos. Em particular, a passagem de mensagens assíncronas que é base para sistemas multiagentes. Nesta seção é apresentado um tipo particular de sistemas multiagentes: o modelo de atores. A seção inicia com um breve histórico, em seguida são apresentados os conceitos fundamentais. Após, então, são detalhadas as formas de interação entre os elementos deste modelo.
2.4.1 Histórico
“O modelo de atores foi motivado pela perspectiva de máquinas de computação altamente paralelas, consistindo em dezenas, centenas ou até mesmo milhares de microprocessadores independentes, cada um com seu próprio processador local de memória e comunicações, comunicando-se através de uma rede de comunicações de alto desempenho". Carl Eddie Hewitt (1973), criador do modelo de atores.
A arquitetura multicore ainda dava seus primeiros passos quando Hewitt (1973) apresentou pela primeira vez modelo de atores. Este modelo surgiu como um modelo
10 Sistemas multiagentes consistem em uma disciplina que vê sistemas complexos como um conjunto de “agentes” em interação. Os agentes são entidades independentes que trabalham em direção a seus próprios objetivos locais. Se a interação for projetada adequadamente, os agentes também poderão atingir metas globais (VAN ROY, 2004, p. 345-346).
matemático11 em ciência da computação, que trata atores como elementos primitivos
universais da computação concorrente. Entretanto, ao contrário dos modelos anteriores de computação, o modelo do ator foi inspirado pela física, incluindo a relatividade geral e a mecânica quântica. Ele também foi influenciado pelas linguagens de programação Lisp, Simula e versões anteriores do Smalltalk, bem como por sistemas baseados em recursos e comutação de pacotes.
Seguindo a publicação de 1973 de Hewitt, a pesquisadora Irene Greif desenvolveu uma semântica operacional12 para o modelo de ator como parte de sua
pesquisa de doutorado (GREIF, 1975). Dois anos depois, Henry Baker e Hewitt publicaram um conjunto de leis axiomáticas para os sistemas de atores (HEWITT e BAKER, 1977). Outros marcos importantes incluem a dissertação de William Clinger (1981), que introduz uma semântica denotacional13 baseada em domínios de poder e
a dissertação de Gul Agha (1985), que desenvolveu ainda um modelo semântico baseado em transição, complementar ao modelo de Clinger. Isso resultou no desenvolvimento completo da teoria do modelo de ator.
2.4.2 Conceitos fundamentais
No modelo de atores, tal como ocorre com conceitos abstratos como objetos do paradigma orientado a objetos, todos os elementos são atores. De maneira bem resumida, um ator é uma entidade computacional que, em resposta a uma mensagem que recebe, pode de maneira concorrente aos demais atores (HEWITT, 1973):
• Enviar um número finito de mensagens para outros atores;
11 Um modelo matemático é uma representação ou interpretação simplificada da realidade, ou uma interpretação de um fragmento de um sistema, segundo uma estrutura de conceitos mentais ou experimentais.
12 Semântica operacional é uma das abordagens de semântica formal, em que o significado de uma construção da linguagem é especificado pela computação que ela induz quando executada em uma máquina hipotética. A semântica operacional preocupa-se mais em como os programas são executados do que meramente com os resultados destas computações. A semântica formal é uma das áreas de estudo de ciência da computação, preocupada em atribuir significado às construções das linguagens de programação.
13 Semântica denotacional designa uma abordagem de semântica formal. A semântica formal é uma das áreas de estudo de ciência da computação, preocupada em atribuir significado às construções das linguagens de programação. Nesta abordagem, os significados são modelados por objetos matemáticos, geralmente funções semânticas definidas composicionalmente, que representam o efeito de executar uma estrutura.
• Criar um número finito de novos atores;
• Designar o comportamento a ser usado para a próxima mensagem que receber.
Em uma mensagem, o remetente não é diretamente acoplado a ela. Este, por sua vez, é representado por um endereço. Este desacoplamento entre remetente e destinatário determina um avanço fundamental ao modelo dado, que permite, desta forma, uma comunicação assíncrona e estruturas de controle como padrões de transmissão de mensagens (HEWITT, 1977).
Figura 9. Diagrama para representação de um ator
Fonte: adaptado de (HEWITT, 1977)
A Figura 9 representa um diagrama com as partes de um ator, a saber: a fila de mensagens na qual estão as mensagens a serem processadas pelo ator por ordem de chegada; a parte relativa ao estado, na qual são armazenadas as informações necessárias para controle do ator; a parte do código fonte, na qual há a lógica para processar as mensagens.
Em suma, o modelo de ator é caracterizado pela concorrência inerente de computação dentro e entre os atores, criação dinâmica de atores, inclusão de endereços de atores em mensagens e interação apenas por meio da passagem direta de mensagens assíncronas sem restrição à ordem de chegada da mensagem (HEWITT, 1977).