Uma máquina virtual para uma linguagem concorrente intermédia

(1)

Faculdade de Ciˆencias

Departamento de Inform´atica

Uma M´aquina Virtual para uma Linguagem Concorrente

Interm´edia

Roberto Rosa da Silva

DISSERTAC

¸ ˜

AO

MESTRADO EM ENGENHARIA INFORM ´

ATICA

Especializac¸˜ao em Engenharia de Software

2013

(2)

(3)

Faculdade de Ciˆencias

Departamento de Inform´atica

Uma M´aquina Virtual para uma Linguagem Concorrente

Interm´edia

Roberto Rosa da Silva

DISSERTAC

¸ ˜

AO

MESTRADO EM ENGENHARIA INFORM ´

ATICA

Especializac¸˜ao em Engenharia de Software

Dissertac¸˜ao orientada pelo Prof. Doutor Francisco Cipriano da Cunha Martins e co-orientado pelo Prof. Doutor Vasco Manuel Thudichum de Serpa Vasconcelos

(4)

(5)

Agradeço, em primeiro lugar, aos meus orientadores, ao Professor Doutor Francisco Martins e ao Professor Doutor Vasco Vasconcelos, pelo apoio e dedicação, pela atenção demonstrada ao longo deste ano e pela objetividade e rigor com que orientaram este tra-balho.

Agradeço também à minha fam´ılia pelo apoio incondicional, paciência e incentivo nos momentos mais dif´ıceis. Sem eles nada disto seria poss´ıvel.

Agradeço também aos meus amigos que estiveram ao meu lado durante esta fase, pelo companheirismo, força e apoio em certos momentos dif´ıceis.

(6)

(7)

A necessidade de aumentar o poder de computação exigiu a produção de hardware com maior capacidade de processamento. Esta situação levou os fabricantes a abandonar o modelo tradicional de Von Neumann e a adotar sistemas com múltiplos processado-res/núcleos. Para que o software acompanhasse a evolução do hardware, as linguagens de programação concorrente ganharam protagonismo, mas com este regressaram os pro-blemas bem conhecidos dos sistemas concorrentes e distribu´ıdos, condições de corrida e impasses.

O mecanismo mais popular que suporta programação concorrente é o uso de múltiplos fios de execução, que partilham variáveis. Neste contexto, propomos o desenvolvimento de uma máquina virtual para a linguagem MIL que imponha, estaticamente, que progra-mas bem tipificados são livres de condições de corrida e não entrem em impasses. A pri-meira propriedade é conseguida através da imposição de uma disciplina no uso de trincos através de tipos singulares; a segunda é alcançada através de anotações polimórficas sobre a ordem pela qual os trincos são fechados. O sistema de tipos recusa programas cujos fios de execução dependam, ciclicamente, uns dos outros no fecho de trincos. No entanto, a introdução de anotações sobre trincos pode introduzir uma complexidade desnecessária no processo de geração de código. De forma a resolver este problema propomos um algoritmo para inferir as anotações polimórficas sobre trincos. A inferência faz-se da re-colha de restrições locais sobre a ordem pela qual os trincos são fechados. As restrições são passadas a um SMT que averigua a sua consistência. Implementámos o algoritmo e experimentámo-lo extensivamente em programas MIL, nomeadamente, em código de alguma dimensão, obtido através da compilação de programas escritos numa linguagem de objetos concorrentes.

Para além disso, pretendemos potenciar a integração da linguagem MIL, quer com lin-guagens de alto n´ıvel que tenham o MIL como alvo de compilação, quer com o desenvol-vimento e integração de outras ferramentas, como, depuradores para multiprocessadores.

Palavras-chave: MIL, linguagem intermédia tipificada, condições de corrida, impasses, multiprocessador.

(8)

(9)

The constant need for computing power required the production of yet more powerful hardware. This induced manufacturers to abandon the traditional Von Neumann model and to embrace systems with multiple processors/nuclei. In order to make the software able to keep the evolution of the hardware, concurrent programming languages come to the rescue, but brought together the well race condition and deadlock problems.

The most popular mechanism that supports concurrent programming is the use of multiple threads, on top shared variables. Within this frame we intend to propose the development of a virtual machine for the MIL language able to guarantee that well-typed programs are free from race conditions and avoiding deadlock situations, statically. The first property is achieved the imposing of a discipline on the use of locks (through sin-gleton types); the second is achieved through polymorphic annotations dictating the order locks are closed. Type system refuses programs whose threads depend on each other in acquiring locks cyclically. However, annotating locks can cause unnecessary complexity in the process of code generation. In order to solve this problem we propose an algorithm to infer the polymorphic annotations of locks. The inference is made by collecting of local restrictions by that gather the order locks are acquired. There restrictions are the passed to an SMT solver that ascertains its consistency. We implemented the algorithm and tested it extensively using MIL programs, particularly in big code obtained by compiling program from a concurrent object oriented language into MIL.

In addition, we intend to enhance MIL language integration, both with high-level concurrent languages targeting MIL, and with the development and integration with de-velopment tools such as, debuggers for multiprocessors.

Keywords: MIL, typed intermediate language, race condition, deadlock, multiprocessor

(10)

(11)

Lista de Figuras xii

Lista de Tabelas xiii

1 Introdução 1 1.1 Motivação . . . 1 1.2 Contribuições . . . 3 1.3 Estrutura do documento . . . 4 2 Trabalho relacionado 5 2.1 Prevenção de impasses . . . 5

2.2 Compilação de linguagens de alto n´ıvel para linguagens intermédias . . . 6

3 MIL 9 3.1 Sintaxe . . . 9

3.2 Exemplo MIL . . . 11

3.3 Sistema de Tipos . . . 13

4 Inferência de anotações para evitar impasses 19 4.1 Anotações para evitar impasses . . . 19

4.2 Algoritmo de inferência de anotações . . . 21

5 Implementação da Máquina Virtual 27 5.1 Tecnologias utilizadas para a construção da máquina virtual do MIL . . . 27

5.1.1 SableCC . . . 27

5.1.2 Z3 . . . 28

5.2 Arquitetura . . . 28

5.3 Fase de An´alise . . . 29

5.3.1 Análise Léxica e Sintática . . . 29

5.3.2 An´alise Semˆantica . . . 29

5.4 Fase de Interpretac¸˜ao . . . 42

5.4.1 M´aquina Abstrata . . . 42

(12)

6.1 Sintaxe . . . 45

6.2 Exemplo . . . 46

7 Compilação de MOOL em MIL 49 7.1 Função de Tradução . . . 49

7.2 Exemplo . . . 57

8 Conclus˜ao 65 A Exemplos Mil 67 A.1 Exemplo com readOnly . . . 67

A.2 Exemplo sem readOnly . . . 70

B Sistema de Tipos 73 B.1 Regras de heap values e heaps . . . 73

B.2 Regras de boa formac¸˜ao dos tipos . . . 73

B.3 Construc¸˜ao do kinding . . . 74

B.4 Regras para valores . . . 74

B.5 Regras de subtipos . . . 74

B.6 Regras para instruc¸˜oes . . . 75

C Regras da Semˆantica Operacional 77 C.1 M´aquina Abstrata . . . 77

C.2 Regras para instruc¸˜oes . . . 77

C.3 Função de avaliação . . . 78

D Restric¸˜oes em Z3 79

E Exemplo de traduc¸˜ao de MOOL em MIL 83

Bibliografia 91

´Indice 92

(13)

3.1 Arquitetura da M´aquina Abstrata . . . 10

3.2 Gram´atica . . . 11

3.3 O jantar dos fil´osofos escrito em MIL . . . 12

3.4 Regra de boa formac¸˜ao . . . 14

3.5 Regras para instruc¸˜oes . . . 14

3.6 Regra de heap value . . . 15

3.7 Excerto do programa do apˆendice A.1 . . . 16

3.8 Novas regras de tipos (extende Fig.3.5) . . . 17

3.9 Relac¸˜ao de ordem dos trincos K ` λ ≺ λ , K ` Λ ≺ λ , K ` λ ≺ Λ , K ` Λ ≺ Λ . . . 17

4.1 O jantar dos filósofos com uma indireção . . . 20

4.2 Algoritmo para colecionar restric¸˜oes . . . 22

5.1 Arquitetura da M´aquina Virtual . . . 29

5.2 Diagrama de classes . . . 30

5.3 Algoritmo para a instruc¸˜aonew . . . 34

5.4 Algoritmo para a regra T-STORE . . . 35

5.5 Algoritmo para as regras T-VALAPPe T-VALAPPLOCK . . . 35

5.6 Representa o predicadosetLessThanLock . . . 38

5.7 Representa o predicadolockLessThanSet . . . 39

5.8 Representa o predicadosetLessThanSet. . . 40

6.1 Sintaxe de utilizador . . . 46

6.2 Fatorial escrito em MOOL . . . 47

6.3 Classe Main . . . 48

7.1 Função de tradução dos métodos printInt eprintBool . . . 51

7.2 Blocospin . . . 55

7.3 Blocospin . . . 61

7.4 BlococalcProd1 . . . 61

7.5 BlocoscalcProd1 continuationewhile calcProd1 . . . 62

7.6 BlococontinueWhile calcProd1. . . 63

(14)

A.2 Resultado do exemplo . . . 70

A.3 Exemplo . . . 72

A.4 Resultado do exemplo . . . 72

B.1 Regras de heap values e heaps . . . 73

B.2 Regras de boa formac¸˜ao dos tipos . . . 73

B.3 Construc¸˜ao do kinding . . . 74

B.4 Regras para valores . . . 74

B.5 Regras de subtipos . . . 74

B.6 Regras para instruc¸˜oes . . . 75

C.1 M´aquina Abstrata . . . 77

C.2 Regras para instruc¸˜oes . . . 78

C.3 Função de avaliação . . . 78

(15)

4.1 Restric¸˜oes geradas durante a primeira passagem do algoritmo . . . 23

4.2 Restric¸˜oes geradas durante a segunda passagem do algoritmo . . . 24

5.1 Constantes e vari´aveis de trincos . . . 36

5.2 O algoritmo numa bancada de trabalho . . . 41

D.1 Restric¸˜oes da primeira passagem em Z3 . . . 80

D.2 Restric¸˜oes da segunda passagem em Z3 . . . 81

(16)

(17)

Introduc¸˜ao

1.1 Motivac¸˜ao

A utilização da informática na resolução de problemas de maior dimensão e complexidade implica, naturalmente, uma necessidade permanente de hardware com maior capacidade de processamento. Esta situação fez com que, num passado recente, os fabricantes tenham abandonado o modelo tradicional de Von Neumann, com uma unidade central de proces-samento, e adotado sistemas com múltiplos processadores ou com múltiplos núcleos por processador. Hoje em dia, a maior parte dos aparelhos eletrónicos usa processadores com múltiplos núcleos, desde computadores pessoais a telemóveis.

No entanto, é fundamental que o software acompanhe a evolução do hardware, de forma a tirar partido do poder de computação extra, oferecido pelos sistemas com pro-cessamento paralelo. Torna-se imperioso o desenvolvimento de novas linguagens de programação concorrentes que ajudem os programadores a lidar com as dificuldades adi-cionais, colocadas pela programação com múltiplos fios de execução. O tema não é novo. Problemas decorrentes de condições de corrida e de impasse remontam aos primórdios da informática. A novidade está na necessidade generalizada de recorrer à programação concorrente, necessidade essa que antes se restringia a um grupo limitado de profissionais altamente competentes.

As mudanças ao n´ıvel das linguagens de programação abrangem os vários n´ıveis de abstração, desde as linguagens de alto n´ıvel até às linguagens de baixo n´ıvel. Devido aos múltiplos processamentos que podem ocorrer em simultâneo, é fundamental garantir que programas escritos em linguagens de alto n´ıvel não incorram em condições de corrida ou em impasses, e que estas verificações sejam preservadas pelo processo de compilação.

As linguagens de programação de alto n´ıvel sofrem transformações substanciais, por exemplo, a criação de primitivas de concorrência num n´ıvel adequado de abstração. Estas transformações equilibram o poder adicionado pela programação concorrente, e dimi-nuem a complexidade nas aplicações. Uma poss´ıvel abordagem para expressar e verificar se os programas das linguagens de alto n´ıvel não entram em condições de corrida nem em

(18)

impasses, em tempo de execução, passa por dotar as linguagens intermédias de tipos, e ti-rar proveito das propriedades de segurança desses tipos, impostas pelos sistemas de tipos. A construção de compiladores que preservam tipos, ao traduzir uma linguagem de alto n´ıvel tipificada numa linguagem intermédia tipificada, ajuda na obtenção de propriedades da linguagem fonte.

Neste sentido, para se tirar o melhor proveito de processadores com múltiplos núcleos, os programadores têm de passar a desenvolver software adequado a este novo paradigma, ou seja, têm de passar a dominar a programação concorrente e paralela.

O mecanismo mais popular que suporta programação concorrente é o uso de múltiplos fios de execução [3], que permite que vários programas sejam executados ao mesmo tempo e que partilhem variáveis. Tal como referimos anteriormente, a programação com múltiplos fios de execução coloca dificuldades como: condições de corrida (race conditi-ons) e impasses.

Uma condição de corrida ocorre quando dois fios de execução tentam aceder à mesma variável e, pelo menos um dos fios de execução escreve na variável.

Uma situação de impasse ocorre quando um programa não progride, ou seja, quando não permite que dois ou mais fios de execução continuem as suas execuções, ficando, por isso, bloqueadas.

A linguagem intermédia MIL é apropriada para o desenvolvimento baixo n´ıvel de sis-temas concorrentes com uso de memória partilhada. O seu sistema de tipos garante que programas MIL bem tipificados não possuem condições de corrida nem impasses [26, 27]. A primeira propriedade é conseguida através da imposição criteriosa de uma disciplina no uso de trincos, através da utilização de tipos singulares [26]. Esta propriedade pode ser conseguida de forma estática, por meio de um sistema de tipos. Em [26], os autores ga-rantem que programas bem tipificados não incorrem em condições de corrida. O sistema de tipos garante que os programas estão bem tipificados, evitando assim os erros mais comuns (saltos para zonas de memória ilegais, operações sobre valores do tipo errado, etc.). O sistema de tipos do MIL faz cumprir uma pol´ıtica de utilização de trincos que pro´ıbe: apanhar um trinco que esteja fechado; libertar um trinco que não está na posse do fio de execução; e obrigar os fios de execução a libertar todos os trincos no final da sua execução.

A segunda propriedade, ausência de impasses, é alcançada através de anotações po-limórficas, sobre a ordem pela qual os trincos devem ser fechados (ou tomados ou adqui-ridos) [3]. O sistema de tipos verifica as anotações polimórficas e recusa programas cujos fios de execução dependam ciclicamente uns dos outros, na obtenção de trincos. Toda-via, a anotação de programas pode complicar o processo de geração de código, pois os conceitos de trinco e de ordem para apanhar o trinco podem não fazer parte da linguagem fonte.

(19)

quer com linguagens de alto n´ıvel que tenham o MIL como alvo de compilação, quer no desenvolvimento e integração de outras ferramentas como, por exemplo, depuradores para multiprocessadores. Para além disso, pretendemos desenvolver um algoritmo para inferir as anotações polimórficas referentes à ordem pela qual os trincos devem ser fechados.

Neste contexto, vimos propor o desenvolvimento de um analisador semântico estático e de uma máquina virtual para a linguagem MIL, que imponha, em tempo de compilação, que programas bem tipificados não acedam a posições de memória inválidas, sendo li-vres de condições de corrida e de impasses. Propomos também o desenvolvimento de um compilador de uma linguagem de objetos concorrentes (MOOL [7]) para a lingua-gem intermédia concorrente MIL. O que é fundamental registar é o facto de ambas as linguagens serem fortemente tipificadas e da linguagem alvo possuir um sistema de ti-pos suficientemente rico para garantir que programas bem tipificados não incorram em condições de corrida e não possuam impasses. Ambas as linguagens, tal como os res-petivos paradigmas subjacentes, diferem substancialmente. A linguagem de alto n´ıvel é orientada a objetos, é baseada na composição e interação entre diversas unidades de software, e a sincronização é semelhante ao mecanismo usado em Java, para evitar inter-ferência entre fios de execução. A linguagem alvo é imperativa e a sincronização é feita através de memória partilhada. O processo de tradução de MOOL para MIL não é direto nem trivial, pois os tipos da linguagem alvo são bastante ricos. A função de tradução que definimos é uma especificação formal do compilador. A tradução da linguagem MOOL para MIL contém a tradução de tipos, de valores, expressões, métodos, classes e operado-res booleanos. O principal objetivo é permitir que o compilador produza programas MIL corretamente tipificados a partir de código fonte correto.

1.2 Contribuic¸˜oes

O analisador semântico para a linguagem MIL evita condições de corrida, o acesso ilegal a tuplos e garante que um programa não atinja impasses. Para além disso, foi constru´ıda uma máquina virtual que interpreta os resultados dos programas.

Tal como referimos anteriormente, a anotação de programas pode complicar o pro-cesso de geração de código. A fim de solucionar este problema, propomos um algoritmo para inferir as anotações polimórficas referentes à ordem pela qual os trincos devem ser fechados num programa MIL. Esta inferência é efetuada através da recolha de restrições locais sobre a ordem pela qual os trincos devem ser tomados em cada bloco de código. As restrições são depois passadas a um SMT [14] que averigua a sua consistência.

As contribuições deste trabalho são as seguintes:

• Implementação de um analisador semântico estático e de uma máquina virtual para a linguagem MIL;

(20)

• Criação de um algoritmo para inferir as necessárias anotações polimórficas sobre a ordem pela qual os trincos devem ser fechados num programa MIL, a fim de assegurar que os programas não atinjam impasses;

• Implementação em Z3 de um resolvedor das restrições geradas pelo algoritmo; teste do algoritmo através da sua aplicação a um grande leque de programas MIL; • Implementação de um compilador de uma linguagem de objetos concorrentes para

uma linguagem interm´edia concorrente.

1.3 Estrutura do documento

Este trabalho encontra-se organizado em sete cap´ıtulos. O cap´ıtulo 2 apresenta uma s´ıntese dos trabalhos j´a realizados e que est˜ao relacionados com o que pretendemos de-senvolver.

O cap´ıtulo 3 define a linguagem MIL. A primeira secção (3.1) define a linguagem MIL através da gramática da linguagem. Na segunda secção (3.2) é apresentado um exemplo de um programa MIL. Por fim (3.3) apresenta o sistema de tipos, que define a análise semântica.

O cap´ıtulo 4 apresenta a discussão dos problemas da inferência de anotações, em par-ticular, como é que a informação sobre as restrições flui através do grafo de chamada dos blocos de código. Na secção 4.2 apresenta-se, detalhadamente, o algoritmo ilustrando-o com exemplos.

O cap´ıtulo 5 descreve o modo como foi desenvolvida a máquina virtual para a MIL. Na secção 5.1 são abordadas as tecnologias usadas para a construção da máquina virtual. A secção 5.2 trata da arquitetura da máquina virtual e a secção 5.3 apresenta o modo como a fase de análise foi implementada e os elementos necessários para a sua construção. Esta inclui um diagrama de classes que representa os tipos da linguagem MIL e apresenta a resolução das restrições em Z3. Na secção 5.4 é abordado o modo como a fase de s´ıntese foi implementada.

O cap´ıtulo 6 define a linguagem de alto n´ıvel (MOOL). No cap´ıtulo 7 é descrita a função de tradução que definimos, uma especificação formal do compilador.

O último cap´ıtulo apresenta as conclusões e o trabalho que nos propomos realizar num futuro próximo.

(21)

Trabalho relacionado

Este cap´ıtulo apresenta uma discuss˜ao mais extensa de trabalhos relacionados com este tema, analisando as principais linhas de pesquisa que inspiraram diretamente esta tese.

A implementação do nosso analisador semântico e da máquina virtual assenta sobre um protótipo já desenvolvido para a linguagem MIL. Este protótipo que se encontra em http://gloss.di.fc.ul.pt/mil/, foi desenvolvido por Tiago Cogumbreiro, Vasco Vasconcelos e Francisco Martins. A especificação da linguagem MIL [11], implementada neste protótipo, é diferente da que se efetuou no decorrer desta tese, porque o seu objetivo é uniformizar a sintaxe da linguagem.

2.1 Prevenc¸˜ao de impasses

A literatura sobre sistemas de tipos para a prevenção de impasses em linguagens baseadas em trincos é vasta. Coffman et al. classificam o problema de impasses em três categorias: deteção e recuperação, impedimento e prevenção [10]. Na primeira categoria, deteção e recuperação, existem alguns trabalhos que verificam se programas atingem impasses, em tempo de execução. Cunningham et al. inferem trincos numa linguagem orientada a objetos, mas usam um mecanismo em tempo de execução para detetar quando é que a aquisição de um trinco, por parte de um fio de execução, atinge um impasse [12]. Java PathFinder [6] e Driver Verifier [2] identificam violações na disciplina do uso de trincos, por via de testes de software.

Na categoria de impedimento, Boudol apresenta uma semântica livre de impasses para uma linguagem de programação concorrente, funcional e imperativa, na qual os trincos são associados a ponteiros [4]. A semântica impede estados inconsistentes por depender de uma análise estática de programas, através de um sistema de tipos e efeitos.

O nosso trabalho assenta sobre a terceira categoria, prevenção. Flanagan e Abadi apre-sentam uma linguagem funcional com referências mutáveis [15]. De forma a resolver o problema de impasses, os trincos são introduzidos na verificação de tipos através de tipos singulares. Com esta introdução pode antecipar-se uma poss´ıvel presença de impasses,

(22)

bem como garantir a ausência de condições de corrida nos programas. A prevenção de impasses também tem sido estudada no âmbito de linguagens orientadas a objetos. Boya-pati et al. utilizam uma variante de tipos de prevenção de impasses em Java, realizando uma inferência parcial de anotações, mas não das que são relacionadas com a ordem dos trincos [5]. Suenaga propõe uma linguagem concorrente funcional idêntica à linguagem de Flanagan e Abadi, exceto na estrutura de blocos [24]. Esta linguagem inclui primitivas separadas para a obtenção e libertação de trincos, tal como no nosso caso.

O nosso algoritmo de inferência tem como base o sistema de tipos de [27]. O sistema de tipos garante que programas MIL bem tipificados não possuam condições de corrida nem impasses. O algoritmo baseado nas regras do sistema de tipos recolhe as restrições e passa-as a um SMT para verificação de consistência.

2.2 Compilac¸˜ao de linguagens de alto n´ıvel para

lingua-gens interm´edias

De seguida, apresentamos alguns compiladores que traduzem linguagens de alto n´ıvel para linguagens intermédias. O que distingue estes compiladores de outros, é que estes são certificados.

Greg Morrisett et al. apresentam um compilador para traduzir Systema F para a lin-guagem intermédia tipificada (TAL) [23]. Uma das caracter´ısticas do TAL é fornecer um conjunto de abstrações embutidas, tais como: números inteiros, tuplos, polimor-fismo e etiquetas de código. Para cada uma destas abstrações são aplicáveis apenas algumas operações, por exemplo, para operações aritméticas apenas é permitido o uso de inteiros e nas operações de transferências de controlo apenas é permitido utilizar eti-quetas de código. Tal como na linguagem TAL, na linguagem MIL o objetivo do sis-tema de tipos é verificar se os programas estão bem tipificados. Este trabalho mos-tra as etapas necessárias para mos-transformar uma linguagem de alto n´ıvel em TAL, man-tendo as informações dos tipos. A primeira etapa da compilação converte código para continuation-passing style[21]. Na segunda etapa da compilação, chamada closure con-version [20], a tradução separa o código do programa de dados, reescrevendo, assim, funções que esperam um argumento adicional. A terceira etapa define os valores do amontoado, que consistem em blocos de código. A quarta etapa faz alocação de memória expl´ıcita. A última etapa da compilação realiza traduções, principalmente sintáticas, como por exemplo, converter variáveis em registos. Uma diferença fundamental en-tre [23] e o nosso trabalho é que não há concorrência em System F nem em TAL.

Adam Chlipala apresenta um compilador certificado do cálculo lambda simplesmente tipificado para uma linguagem intermédia [9]. A certificação de compiladores é um método que verifica a semântica do código gerado. Chlipala tenta mostrar as vantagens de fazer um compilador que preserva tipos e um compilador orientado a tipos. Os

(23)

com-piladores que preservam os tipos guardam a informação dada pelos tipos até à última fase da compilação, permitindo, assim, uma compilação mais segura e que preserva a semântica. O compilador orientado a tipos (exemplo, Typed Intermediate Language for the ML language [TIL] [25]) demonstra que o uso de uma linguagem intermédia, forte-mente tipificada, aumenta não só a segurança, mas também a eficiência.

Por fim, Tiago Cogumbreiro et al. apresentam uma tradução que preserva os tipos do cálculo π para o MIL [11]. Em cálculo π, os processos comunicam através da passagem de mensagens, no MIL, os fios de execução comunicam através de memória partilhada. Para ajudar na tradução, foram usados monitores de Hoare, estes introduzem uma forma de sincronizar os fios de execução. A tradução do cálculo π para MIL suporta a tradução de tipos, de valores e de processos. Na nossa tradução, também é suportada a tradução de tipos e de valores. Porém, como a linguagem MOOL não é uma linguagem de processos, não suportamos a tradução de processos, mas a de objetos.

(24)

(25)

MIL

Neste cap´ıtulo apresentamos a sintaxe e semântica da linguagem de programação MIL— Multithreaded Intermediate Language. A linguagem MIL destaca-se pela sua semântica estática imposta por um sistema de tipos, que garante, em tempo de compilação, que programas bem tipificados não acedam a posições de memória inválidas e sejam livres de condições de corrida e de impasses.

A linguagem MIL destina-se a programar uma máquina abstrata com vários proces-sadores, cuja memória principal é partilhada (cf. figura 3.1). Cada processador tem um conjunto de registos, uma memória local, para instruções, e um conjunto de trincos fe-chados. A memória principal é dividida em duas partes: um amontoado e uma piscina para os fios de execução suspensos. O amontoado armazena blocos de dados e blocos de código: os primeiros são representados por tuplos e são partilhados entre os vários proces-sadores; os segundos são compostos por uma assinatura e por um conjunto de instruções. A assinatura contém a descrição dos tipos dos registos utilizados e os trincos fechados necessários. A piscina de fios de execução contém os fios de execução que estão à espera de um processador livre.

3.1 Sintaxe

A figura 3.2 apresenta a gramática da linguagem MIL. Esta gramática está escrita segundo a notação Backus-Naur Form (BNF), notação muito utilizada para expressar gramáticas de linguagens de programação [22].

Os programas MIL estão organizados em blocos, que são identificados por etiquetas, representadas por l. Os programas podem também conter abreviaturas de tipos, o que permite definir identificadores de tipos globais, com o objetivo de atribuir um tipo a um identificador, permitindo a existência de tipos recursivos. As etiquetas identificam três tipos de blocos: os blocos de dados, os valores de trincos e os blocos de código.

Os valores da linguagem incluem os registos, os números inteiros, as etiquetas do programa, os valores de trinco, os tipos não inicializados (valor usado apenas na criação

(26)

CPU núcleo 1

CPU núcleo N

registos instruções

piscina para fios de execução amontoado

Figura 3.1: Arquitetura da M´aquina Abstrata

de um novo tuplo) e a aplicação de valores (permite instanciar os tipos polimórficos). Os valores de trinco são 0 e 1; 0 representa um trinco aberto e 1 um trinco fechado. O modo de acesso permite definir o tipo de proteção de um tuplo. O tuplo pode ser protegido por λ ou porreadOnly, e a única forma de criar tuplos protegidos porreadOnly

é usando a instruçãonewRO.

Uma sequência de instruções termina ou com a instrução jump ou com a instrução

done. A instrução jump continua a execução no bloco indicado na instrução de salto; a instrução done termina o fio de execução, ficando o processador dispon´ıvel para executar outro fio de execução.

Relativamente aos tipos, a linguagem contém inteiros, strings, variáveis de tipo (λ), lock(lock λ), tuplos, bloco de código (ΓrequiresΛ), o tipo não inicializado (?τ ), tipos po-limórficos e tipos existenciais. O tipo inteiro representa os valores inteiros. O tipo string representa sequencias de caracteres. A variável de tipo é usada para descrever o tipo sin-gular do valor que está num trinco. O tipo lock descreve um trinco do programa. O tipo de tuplos (h~τ iπ_{) descreve um tuplo protegido por π. O tipo Γ requires Λ representa um bloco}

de código; Γ indica quais os tipos esperados para os registos e Λ representa as permissões necessárias para poder aceder à etiqueta em questão. O tipo não inicializado descreve valores de um dado tipo, que não estejam inicializados. Este simboliza o tipo futuro de uma determinada posição de um tuplo, por exemplo, h?intiλ, indica que o tipo da posição 1 do tuplo não está inicializado, mas que será um inteiro. Os tipos polimórficos permitem abstrair tipos, e possibilitam o tratamento de vários tipos de uma forma homogénea. Por fim, os tipos existências têm a função de esconder a variável de tipos, impedindo que os tipos fiquem dependentes desta.

(27)

registos r ::= r1 | . . . | rR

n´umeros inteiros n ::= . . . | -1 | 0 | 1 | . . .

strings s ::= ”...”

valores de trincos b ::= 0λ | 1λ

valores v ::= r | n | s | l | b | ?τ | v[λ] | pack τ, v as τ modo de acesso π ::= λ | readOnly

instruc¸˜oes ι ::=

dados/controlo de fluxo r := v | r := v + v | if r = 0λjump r | mem´oria r :=new τ | r := r[n] | r[n] := r |

r :=newRO h~vi

unpack ω, r :=unpack v |

lock r :=getSetLock r | unlock r | λ :: Lock |

concorrˆencia fork r

sequência de instruções I ::= ι; I | jump r | done

tipos τ ::= int | string | λ | lock λ | h~τ iπ | Γ requires Λ | ?τ | ∃ω.τ | ∀α.τ | τ [τ ] | id

tipos de registos Γ ::= {r1: τ1, . . . , rn: τn}

permiss˜oes Λ ::= {λ1, . . . , λn}

amontoado de valores h ::= h~vi | {I} | b

entradas do amontoado e ::= type id = τ | l :: τ | l = h | λ :: Lock programas ou amontoados H ::= {e1, . . . , en}

Figura 3.2: Gram´atica

3.2 Exemplo MIL

A figura 3.3 ilustra uma implementação do famoso problema do jantar de filósofos [19] escrito em MIL. O programa é composto por quatro blocos de código, identificados pelas etiquetasmain,levantarGarfoEsquerdo, levantarGarfoDireito ecomerEFilosofar.

Começamos por apresentar as assinaturas dos quatro blocos de código do programa. A primeira linha contém a assinatura do blocomain, que não indica restrições, nem ao n´ıvel do tipo dos registos, nem dos trincos requeridos, o que se justifica por ser o ponto de entrada da execução do programa. Por sua vez, a linha 11 contém a assinatura do blocolevantarGarfoEsquerdo. Neste caso, é requerido que aquando de um salto para, ou do lançamento de um fio de execução comlevantarGarfoEsquerdo, os registos r1 e r2 de-verão conter dois trincos que, neste caso, se encontram abstra´ıdos universalmente. Já as definições de levantarGarfoDireito (linha 17) e decomerEFilosofar(linha 23) exigem, adici-onalmente, a posse do trincoe, na primeira, e dos trincoseed, na segunda.

(28)

main :: {} 2 main = {

g1::Lock r3 := new lock g1 unlock r3 −− primeiro garfo

4 g2::Lock r4 := new lock g2 unlock r4 −− segundo grafo

g3::Lock r5 := new lock g3 unlock r5 −− terceiro grafo

6 r1 := r3 r2 := r4 fork levantarGarfoEsquerdo[g1][g2] −− primeiro filosofo

r1 := r4 r2 := r5 fork levantarGarfoEsquerdo[g2][g3] −− segundo filosofo

8 r1 := r5 r2 := r3 fork levantarGarfoEsquerdo[g3][g1] −− terceiro filosofo done

10 }

levantarGarfoEsquerdo :: ∀ e ::Lock.∀ d::Lock.{r1: lock e, r2: lock d}

12 levantarGarfoEsquerdo = { r3 := getSetLock r1

14 if r3 == 0 jump levantarGarfoDireito[e][d] jump levantarGarfoEsquerdo[e][d]

16 }

levantarGarfoDireito :: ∀ e ::Lock.∀ d::Lock.{r1: lock e, r2: lock d} requires {e}

18 levantarGarfoDireito = { r3 := getSetLock r2

20 if r3 == 0 jump comerEFilosofar[e][d] jump levantarGarfoDireito[e][d]

22 }

comerEFilosofar :: ∀ e ::Lock.∀ d::Lock.{r1: lock e, r2: lock d} requires {e,d}

24 comerEFilosofar = { −− comer

26 unlock r1 −− pousa o garfo esquerdo unlock r2 −− pousa o garfo direito

28 −− pensar

jump levantarGarfoEsquerdo[e][d]

30 }

Figura 3.3: O jantar dos fil´osofos escrito em MIL

que representam os três garfos que os filósofos partilham (linhas 3–5). Analisando a li-nha 3 em detalhe, o trincog1 é declarado (g1::Lock), de seguida é reservada memória no amontoado para o guardar, ficando a referência para a memória guardada no registo r3

(r3 := new lock g1). Por último, o trinco é aberto (unlock r3), pois o fio de execução que cria um trinco fica com a sua posse e neste exemplo podemos liberta-lo de imediato. As linhas 6–8 lançam os fios de execução referentes aos três filósofos. Por exemplo, no caso do filósofo 1, são carregados nos registos r1 e r2, as referências respeitantes aos trincos g1 e g2 e, de seguida, a instrução fork lança um novo fio de execução que irá executar o blocolevantarGarfoEsquerdo. Note-se que os parâmetros de tipo eedsão ins-tanciados com os trincos g1 e g2, respetivamente. No instante do lançamento de cada fio de execução, os tipos dos registos em main coincidem com os tipos esperados pelo bloco levantarGarfoEsquerdo. Para tal, verifique-se que aquando do lançamento do fio de execução do terceiro filósofo (linha 8) o registo r1 refere o trincog3, enquanto o re-gistor2 refere o trinco g1, o que está de acordo com a instanciação dos argumentos de tipolevantarGarfoEsquerdo[g3][g1].

(29)

A instrução done (linha 9) termina o fio de execução, deixando o processador dis-pon´ıvel para executar outro fio de execução, que esteja a aguardar na piscina de fios de execução.

Os blocos de c´odigolevantarGarfoEsquerdo e levantarGarfoDireito fecham os trincos e

ed, que representam os garfos esquerdo e direito do filósofo. O blocolevantarGarfoEsquerd otenta fechar o trincoe, utilizando a instruçãogetSetLock(linha 13). Esta instrução, de forma indivis´ıvel, obtém o valor do trinco indicado pelo registo r1 e fecha-o. O teste na linha 14 verifica se o trinco estava aberto anteriormente. Se tal se verificar, signi-fica que o fio de execução fechou o trinco e, nesse caso, o controle passa para o bloco

levantarGarfoEsquerdo. Caso contrário, volta a tentar fechar o trinco, utilizando o método da espera ativa (linha 15). O blocolevantarGarfoDireito é semelhante aolevantarGarfoEsquer do, excetuando o facto de o blocolevantarGarfoEsquerdo requerer que o trincoejá tenha sido fechado, para além disso, tenta fechar o trincode, quando tal acontecer, salta para o bloco de códigocomerEFilosofar.

Por ´ultimo, no blococomerEFilosofar, o fil´osofo come e pousa os garfos, libertando, para tal, os trincos referidos por r1e r2 (linhas 26 e 27), pensa e inicia uma nova ronda (linha 29).

Para consultar, com maior detalhe, a semˆantica operacional, leia-se o apˆendice C.

3.3 Sistema de Tipos

Um sistema de tipos para uma linguagem de programação é composto por um conjunto de regras (de tipos) [8]. O propósito de um sistema de tipos é evitar a ocorrência de erros de execução no decorrer dos programas [8].

A descrição de um sistema de tipos é representada por regras de inferência (regras de tipos), compostas por sentenças. A sentença mais importante é o sequente. Segue-se um exemplo de uma destas regras, em que K é o conjunto de permissões, Ψ é uma tabela que tem etiquetas como chave e, como valor, os tipos das etiquetas e em que Γ é uma tabela que tem registos como chave e, como valor, os tipos dos registos. A regra afirma que a etiqueta l tem o tipo τ em Ψ.

K; (Ψ, l : τ ); Γ ` l : τ

As regras de tipo afirmam a validade de determinadas sentenc¸as, com base noutras j´a conhecidas. Podemos tomar como exemplo:

K ` τ K; Ψ; Γ `?τ : ?τ

Cada regra de tipo é representada por premissas, acima da linha horizontal. A con-clusão encontra-se abaixo dessa linha. Quando o número de premissas é 0, a regra diz-se um axioma. Quando todas as premissas são satisfeitas, então a conclusão é verdadeira.

(30)

K ` ∀l.τ K ` τ0

K ` ∀l.τ [τ0_]

Figura 3.4: Regra de boa formac¸˜ao

K ` h~τiλ _{K; Ψ; Γ{r : h ~}_{?τ i}λ_{}; Λ ` I}

K; Ψ; Γ; Λ ` r := new h~τiλ_{; I} (T-NEWTUPLE)

K; Ψ; Γ{r : lock λ}; Λ, λ ` I

K; Ψ; Γ; Λ ` r := new lock λ; I (T-NEWLOCK) K; Ψ; Γ ` r0_{: h..τ}

n..iπ K; Ψ; Γ{r : τn}; Λ ` I τn 6=? π ∈ Λ

K; Ψ; Γ; Λ ` r := r0_{[n]; I} (T-LOAD)

K; Ψ; Γ ` ~v : ~τ K; Ψ; Γ{r : h~τireadOnly_{}; Λ ` I}

K; Ψ; Γ; Λ ` r := newRO h~viI (T-NEWRO) K, λ :: Lock; Ψ; Γ; Λ ` I

K; Ψ; Γ; Λ ` λ :: Lock; I (T-LOCK)

Figura 3.5: Regras para instruc¸˜oes

O sistema de tipos proposto para a linguagem MIL segue a tradição das linguagens intermédias tipificadas, como por exemplo o TAL [23]. As verificações do sistema de tipos são efetuadas estaticamente, ou seja, determinadas em tempo de compilação.

Nesta secção, apresentamos novas regras que surgiram com a alteração da sintaxe da linguagem e as regras do sistema de tipos com anotações, de forma a mostrar como é efetuada a prevenção de impasses em programas anotados, apresentada em [27]. As restantes regras encontram-se no apêndice B.

A regra da figura 3.4 apresenta uma regra de boa formação de tipos. O sequente (K ` ∀l.τ [τ0]) destas regras, tem de conter o conjunto de trincos, porque a verificação da boa formação dos tipos é baseada neste conjunto. Esta regra certifica que a aplicação de tipos está bem formada. Para tal, é necessário que os tipos τ e τ0 estejam bem formados. Para além disso o tipo ao qual é efetuada a aplicação tem de ser um tipo universal (∀l.τ ). Esta regra é utilizada para verificar a inicialização de tipos definidos, de forma a poder usá-los ao longo dos programas.

As regras da figura 3.5 apresentam as regras de tipos para instruções. No sequente (K; Ψ; Γ; Λ `) destas regras, necessitamos do conjunto de trincos, do conjunto de per-missões e das tabelas Ψ e Γ porque, para a verificação das instruções, estas estruturas são úteis. A regra T-NEWTUPLE assegura que o tuplo de tipos tem de estar bem formado. Neste caso, é atribu´ıdo ao registo r o tuplo de tipos, em que os tipos do tuplo ficam como tipos não inicializados.

(31)

K ` τ K; Ψ{id : τ }; Γ; Λ

K ` type id = τ ; Ψ; Γ; Λ (T-TYPE)

Figura 3.6: Regra de heap value

lock. Para além disso, λ também é adicionado ao conjunto de permissões, porque o trinco λ é fechado neste ponto do programa.

Na regra T-LOADverifica-se se o registo r’ ´e um tuplo de tipos e se o π que protege o

tuplo de tipos, é um λ. No caso de ser λ, este tem que pertencer ao conjunto de permissões pois, caso contrário, o tuplo é protegido porreadOnly. O tipo que se encontra no ´ındice n do tuplo tem de estar inicializado, e é adicionado a Γ o registo r, com o tipo que está no ´ındice n. Pois no caso de o tipo não estar inicializado, é indicador de que não foi atribu´ıdo nenhum valor à posição n do tuplo.

Na regra T-LOCK, o trinco λ ´e adicionado ao conjunto de trincos, porque o trinco ´e declarado neste ponto do programa.

O intuito da regra T-NEWRO é verificar se o tuplo de valores h~vi está bem formado. Ao registo r é atribu´ıdo um tuplo de tipos h~τ i, com os tipos dos valores do tuplo h~vi, que é protegido porreadOnly. Esta regra é eficaz quando um tuplo é partilhado por vários processadores e todos necessitam de ler o conteúdo do tuplo. Ao existir um tuplo prote-gido porreadOnly, não é necessário obter nenhum trinco para se aceder ao conteúdo do tuplo. Caso esta regra não existisse, seria necessário obter o trinco do tuplo partilhado por vários processadores, assim, todos os processadores teriam de esperar que o processador que tivesse o trinco fechado o libertasse. Por exemplo, nas figuras A.1 e A.3 apresenta-mos um exemplo que usufrui da instruçãonewRo(figura A.1) e outro que, em vez utilizar a instruçãonewRo, utiliza um trinco global (figura A.3). O objetivo de ambos os exem-plos é o mesmo: imprimir, usando dois processadores diferentes, os números de 50 até 60 e de 10 até 0. Com estes exemplos, pretendemos demonstrar a vantagem de usar a instruçãonewRo. Com a instruçãonewRo, os números não são apresentados na consola de forma sequencial, ou seja, os números de 50 até 60 estão intercalados com os número de 10 até 0, indicando que os processadores conseguem, em simultâneo, aceder à estrutura definida no programa (linha 1). Por fim, sem a instruçãonewRo, os números são apresen-tados, na consola, de forma sequencial, ou seja, primeiro são mostrados os números de 50 até 60 e depois os número de 10 até 0, ou vice-versa. Isto acontece porque um dos processadores fica à espera que o outro processador liberte o trincolockReadque protege o tuplo<<int> guarded by b, lock b>.

A figura 3.6 representa o modo como os identificadores de tipos globais devem ser utilizados. É adicionado ao Ψ o idcom o tipo τ , e o tipo τ tem de estar bem formado. O objetivo desta regra é permitir definir os nossos próprios tipos. Para além disso, possibilita a introdução de tipos recursivos na nossa linguagem.

(32)

printInt :: ∀ l2 :: Lock. {r1: lock l2 , r2: <int> guarded by l2, r3 : int , r4:∀ l3 :: Lock.{

r1:lock l3 , r2: <int> guarded by l3} requires {l3}} requires {l2}

2 printInt = { r32 := printLock 4 r33 := getSetLock r32 if r33 == 0 jump printIntCritical [ l2 ] 6 jump printInt [ l2 ] } 8

printIntCritical :: ∀ l2 :: Lock. {r1: lock l2 , r2: <int> guarded by l2, r3 : int , r4:∀ l3 :: Lock.{r1: lock l3 , r2: <int> guarded by l3} requires {l3}} requires {consoleLock, l2}

10 printIntCritical = {

r5 := console r5 [1] := r3 r3 := printLock

12 unlock r3 jump r4[l2]

14 }

Figura 3.7: Excerto do programa do apˆendice A.1

O exemplo da figura 3.7 ilustra o modo como se apresentam os resultados na consola. A apresentação de resultados na consola, neste caso, é conseguida através das etiquetas

printInt e printIntCritical da figura.

Para se poder visualizar o resultado de programas MIL, foram adicionadas duas en-tradas especiais:

• console :: <int, string>ˆconsoleLock

• printLock :: lock consoleLock

printLock = 0

Para se visualizar o resultado, é necessário guardar o valor a visualizar no tuplo que existe por defeito, o console. Como a linguagem MIL só tem, como tipos primitivos, inteiros e strings, então o tuplo só tem o tipo int e string. No caso de vir a surgir, por exemplo, o tipoboolean, basta adicionar esse tipo ao tuplo, ficando:

• console: <int, string, boolean>ˆconsoleLock.

Assim, para se poder visualizar o resultado na consola seria necess´ario:

1. atribuir o lock consoleLocka um registo, para se poder fazer um getSetLock sobre esse registo e obter o valor do trinco;

2. fazer um salto condicional para a etiqueta que requer olock consoleLock;

3. atribuir ao registo r a etiqueta console que cont´em o tuplo especial que permite apresentar os resultados na consola;

(33)

kindings K ::= ∅ | K, λ :: Lock(Λ, Λ) τ <: τ0 ∀λ :: Lock(Λ1, Λ2).τ <: ∀λ ::Lock(Λ1, Λ2).τ0 (subtyping) K ` Λ₁, Λ2 λ 6∈ Λ1, Λ2 K 6` Λ2 ≺ Λ1 K ` λ :: Lock(Λ1, Λ2) K ` λ :: Lock(Λ1, Λ2) K, λ ::Lock(Λ1, Λ2) ` τ K ` ∀λ :: Lock(Λ1, Λ2).τ

(well formed types) K ` λ K; Ψ; Γ ` v : ∀λ0::Lock(Λ1, Λ2).τ K ` Λ1 ≺ λ ≺ Λ2 K; Ψ; Γ ` v[λ] : τ [λ/λ0_] (T-VALAPPLOCK) K; Ψ; Γ ` r : λ K; Ψ; Γ ` r0: Γrequires (Λ ] {λ}) K; Ψ; Γ; Λ ` I K ` Λ ≺ λ K; Ψ; Γ; Λ ` if r = 0λjump r0_{; I} (T-CRITICAL) K ` λ :: Lock(Λ1, Λ2); Ψ; Γ ` v : ∃ω.τ K, λ :: Lock(Λ1, Λ2); Ψ; Γ{r : τ }; Λ ` I λ 6∈ K K; Ψ; Γ; Λ ` λ, r := unpack v; I (T-UNPACK) K ` λ :: Lock(Λ1, Λ2) K, λ :: Lock(Λ1, Λ2); Ψ; Γ; Λ ` I K; Ψ; Γ; Λ ` λ :: Lock(Λ1, Λ2); I (T-LOCK) K ` ∀~λ :: Lock(~Λ1, ~Λ2).Γrequires Λ K, ~λ :: Lock(~Λ1, ~Λ2); Ψ; Γ; Λ ` I

K; Ψ ` ∀~λ :: Lock(~Λ1, ~Λ2).Γrequires Λ {I} : ∅

(heap values)

Figura 3.8: Novas regras de tipos (extende Fig.3.5)

K(λ) = (Λ₁, ) λ1 ∈ Λ1 K ` λ1 ≺ λ K(λ) = ( , Λ₂) λ2 ∈ Λ2 K ` λ ≺ λ2 K ` λ₁≺ λ₂ K ` λ₂ ≺ λ₃ K ` λ1 ≺ λ3 K ` λ_i ≺ λ (1 ≤ i ≤ n) K ` {λ1, . . . , λn} ≺ λ K ` λ ≺ λ_i (1 ≤ i ≤ n) K ` λ ≺ {λ1, . . . , λn} K ` λ₁ ≺ Λ (1 ≤ i ≤ n) K ` {λ1, . . . , λn} ≺ Λ

Figura 3.9: Relac¸˜ao de ordem dos trincos K ` λ ≺ λ , K ` Λ ≺ λ , K ` λ ≺ Λ , K ` Λ ≺ Λ

4. apresentar os resultados armazenando-os na posição 1 do registo r, no caso de in-teiros, e na posição 2, no caso de strings.

A figura 3.8 apresenta uma extensão ao sistema de tipos base da linguagem MIL. Que tem como objetivo evitar impasses em programas MIL [27]. Os impasses, geralmente, são impedidos pela imposição de uma ordem parcial rigorosa de trincos, obrigando os programas a respeitar essa ordem quando adquiram trincos [3, 10, 15]. Como se pode verificar através das regras da figura 3.8, os trincos são decorados com Λ1 e Λ2. Λ1 representa o conjunto de trincos menores do que o trinco λ e Λ2 representa o conjunto de trincos maiores do que o trinco λ. Para fazer a verificação, é necessário ter uma relação (≺) de ordem entre os trincos, expressa na figura 3.9.

(34)

Na regra T-CRITICAL, obtemos uma restrição em que o conjunto de permissões do tipo do registo r’ tem de ser menor que o trinco obtido pela regra T-CRITICAL, ou seja,

a restrição é Λ ≺ λ. Na regra T-VALAPP, as restrições obtidas são: λ é menor que o conjunto de trincos maiores de λ0e o conjunto menor de λ0é menor do que λ. Para além de adicionar estas restrições, a substituição das variáveis também é feita nos conjuntos de λ0. Por fim, as regras T-LOCK, T-UNPACK eheap values recorrem à regra da boa formação dos tipos, para esta verificar se os conjuntos Λ1 e Λ2 estão bem formados, ou seja, se os trincos que estes contêm estão no dom´ınio dos conjuntos de trincos, e adiciona duas restrições: λ 6∈ Λ1, Λ2 e Λ1 ≺ Λ2.

A figura 3.9 apresenta a relação de ordem entre os trincos. O trinco λ1 é menor que o

trinco λ se o trinco λ1pertencer ao conjunto de trincos menores (Λ1) de λ ou se o trinco

λ pertencer ao conjunto de trincos maiores de λ1. O conjunto Λ1 ´e menor que o trinco λ,

se todos os trincos do conjunto Λ1 forem menores que o trinco λ. No caso, λ ≺ Λ2, λ é menor que o conjunto Λ2, se λ for menor que todos os trincos de Λ2. Também é feita a relação entre dois conjuntos, ou seja, o conjunto Λ1 é menor que o conjunto Λ2 se todos os trincos de Λ1 forem menores que cada trinco do conjunto Λ2.

(35)

Inferência de anotações para evitar

impasses

4.1 Anotac¸˜oes para evitar impasses

Um impasse ocorre quando um programa não consegue progredir porque os seus fios de execução necessitam de recursos que estão detidos por outros fios de execução e vice-versa. A figura 3.3 apresenta um caso simples de um programa que, quando executado, poderá eventualmente atingir um impasse. Na verdade, há um escalonamento que per-mite que cada filósofo possa apanhar o garfo à sua esquerda (levantarGarfoEsquerdo) e ficar indefinidamente à espera de apanhar o garfo à sua direita (ciclo de espera ativa em

levantarGarfoDireito). Esta situação é facilmente evitada substituindo a instruçãofork

levan-tarGarfoEsquerdo[g3][g1]da linha 8 porfork levantarGarfoEsquerdo[g1][g3], ou seja, trocando as voltas (ou antes, os brac¸os) ao terceiro fil´osofo.

Mas como determinar, sem executar o programa da figura 3.3, que este tem um esca-lonamento que pode levar a um impasse, e que a variante que propomos nunca atinge um impasse? O sistema de tipos apresentado na secção 3.3 consiste em decorar as variáveis de trinco com anotações (locais e polimórficas) de ordem, conduzindo a uma ordem (par-cial) global para o fecho dos trincos. Por sua vez, o sistema de tipos verifica que de facto o programa fecha os trincos por esta ordem. A tarefa de anotar um programa pode com-plicar a geração de código, porque em alguns casos a informação sobre a ordem de fecho de trincos está ausente do processo de compilação (isto foi-nos dado observar na escrita de um compilador de uma linguagem de objetos concorrentes em MIL, cap´ıtulo 7).

A figura 4.1 apresenta uma generalização do blocolevantarGarfoEsquerdo (cf. figura 3.3), além de tornar expl´ıcitas algumas anotações polimórficas sobre os trincos. O obje-tivo é ilustrar a dificuldade em inferir estas anotações. Note-se que este simples programa de 35 linhas contém 16 anotações relacionadas com ordens de trincos (linhas 4-5, 14-15, 22 e 29). Nesta versão, o blocolevantarGarfoEsquerdorecebe no registor6 o endereço da sua continuação, usado na instruçãojump(linha 18) em lugar do nome expl´ıcito do bloco

levantarGarfoDireito, tal como acontece com o c´odigo na figura 3.3 (linha 14).

(36)

2 main = {

g1::Lock r3 := new lock g1 unlock r3 −− primeiro garfo

4 g2::Lock({g1},{}) r4 := new lock g2 unlock r4 −− segundo grafo g3::Lock({g1,g2},{}) r5 := new lock g3 unlock r5 −− terceiro grafo

6 r1 := r3 r2 := r4 r6 := levantarGarfoDireito [g1]

fork levantarGarfoEsquerdo[g1][g2] −− primeiro filosofo

fork levantarGarfoEsquerdo[g2][g3] −− segundo filosofo

fork levantarGarfoEsquerdo[g3][g1] −− terceiro filosofo

12 done

}

14 levantarGarfoEsquerdo::∀ e::Lock({},{}).∀ d::Lock.{r1:lock e,r2:lock d,

r6:∀ l ::Lock({e},{}).{r1:lock e,r2:lock l } requires {e}}

16 levantarGarfoEsquerdo = { r3 := getSetLock r1 18 if r3 == 0 jump r6[d] jump levantarGarfoEsquerdo[e][d] 20 } levantarGarfoDireito ::

22 ∀ e1::Lock({},{}).∀ d1::Lock({e1},{}).{r1:lock e1,r2:lock d1} requires {e1} levantarGarfoDireito = { 24 r3 := getSetLock r2 if r3 == 0 jump comerEFilosofar[e1][d1] 26 jump levantarGarfoDireito[e1][d1] } 28 comerEFilosofar::

∀ e2::Lock({},{}).∀ d2::Lock({},{}).{r1:lock e2,r2:lock d2} requires {e2,d2} 30 comerEFilosofar = {

...

32 r6 := levantarGarfoDireito [e2]

jump levantarGarfoEsquerdo[e2][d2]

34 }

Figura 4.1: O jantar dos filósofos com uma indireção

Voltemos a nossa atenção para o bloco main. Cada declaração de trinco (linhas 4-5) é decorada com dois conjuntos, por exemplo g2::Lock({g1},{}), que contêm os trincos que devem ser fechados antes—{g1}—e depois—{}—de g2. Assim, é poss´ıvel estabe-lecer uma relação de ordem parcial entreg2e os demais trincos vis´ıveis neste ponto do programa. As declarações polimórficas de blocos de código são também anotadas com conjuntos com igual semântica (vide linhas 14–15, 22 e 29). Na ausência de uma dada anotação, o algoritmo que propomos na secção seguinte, anota a variável de trinco, não com conjuntos concretos, mas com variáveis—L0, L1,. . . —sobre conjuntos de trincos. Será tarefa do algoritmo concretizar estas variáveis de modo a que o programa passe no sistema de tipos.

A ordem pela qual os trincos são fechados é determinada quando um fio de execução, tendo na sua posse alguns trincos fechados, tenta fechar o próximo trinco. Neste ponto do programa ficamos com a indicação de que os trincos já fechados têm de ser menores do que o trinco que se está a tentar fechar. Pretendemos recolher esta informação (na forma

(37)

de restrições) e depois verificar se a informação é consistente, ou seja, se as restrições recolhidas não levam a concluir que para fechar um trinco é necessário ter já este mesmo trinco fechado.

Tomando o exemplo da figura 4.1, note-se que, na linha 25, se pretende fechar o trincod1 tendo já o trinco e1 fechado (veja-se a menção requires{e1} na assinatura do bloco de código, na linha 22). Mas repare-se que e1 e d1 não são trincos concretos do programa; antes, correspondem a parâmetros de tipo que são substitu´ıdos em tempo de execução pelos trincos g1, g2 e g3. Esta informação é obtida através da análise do corpo dos blocos de código e é expressa em termos da informação local, na maior parte das vezes referente a parâmetros polimórficos. A relação dos trincos concretos com os trincos polimórficos é conseguida através das restrições obtidas no algoritmo apresen-tado na secção seguinte. Tal como no exemplo da figura 3.3 há um escalonamento que permite que cada filósofo possa apanhar o garfo à sua esquerda (levantarGarfoEsquerdo) e ficar indefinidamente à espera de apanhar o garfo à sua direita (ciclo de espera ativa em levantarGarfoDireito). O problema é resolvido, como no exemplo da figura 3.3, subs-tituindo a instruçãofork levantarGarfoEsquerdo[g3][g1]da linha 11 porfork levantarGarfoEs

querdo[g1][g3].

4.2 Algoritmo de inferência de anotações

A figura 4.2 apresenta o pseudo-código do nosso algoritmo. Este efetua duas passagens sobre o código fonte. Na primeira passagem associa duas novas variáveisLi1eLi2a cada trinco li declarado e gera restrições que relacionam Li1, Li2 e li (1.1). Estas variáveis são definidas sobre conjuntos de trincos e denotam os trincos a apanhar antes (Li1) e de-pois (Li2) do trinco em questão. As restrições geradas capturam estes factos: o trinco li

é apanhado após todos os trincos em Li1 e antes de qualquer trinco em Li2. Estas três restrições,Li1 < li, li < Li2 eLi1 < Li2, são escritas abreviadamente comoLi1 < li < Li2. Adicionalmente, requeremos que os trincos deLi1e deLi2correspondam a trincos que es-tejam no âmbito do bloco ou da instrução em causa. Caso contrário, a solução encontrada pode ser inválida por mencionar trincos declarados noutro ponto do programa. No caso de um trinco li conter anotações (1.2), essas anotações são colecionadas nesta fase do algoritmo através de restrições. Neste caso, as restrições adicionadas registam o valor que as variáveis de conjuntos de li devem assumir, ou seja,Li1 = MieLi2 = Ni, em queLi1eLi2

são as variáveis associadas ao trinco li, eMie Nicorrespondem aos conjuntos definidos na anotação do trinco li.

A primeira passagem no exemplo da figura 4.1, enumera os conjuntos sequencial-mente (começando emL0), resulta que na linha 3 são associadas ag1as variáveisL0eL1

e as restriçõesL0 < g1 < L1,L0⊆ ∅ eL1⊆ ∅. Na linha 14, por exemplo, são associadas ao

(38)

// Primeira passagem

1. Analisar cada bloco do programa:

1.1 para cada trinco li definido na assinatura de um bloco de código (da forma ∀li ::Lock.t), no corpo de um bloco (da forma li ::Lock), ou numa instrução unpack (da forma li , r:=unpack v), associar-lhe duas novas variáveis sobre conjuntos de trincos Li1 e Li2 e incluir as seguintes restrições: Li1 < li < Li2, Li1 ⊆ Trincos,

Li2 ⊆ Trincos, em que Trincos representa o conjunto de trincos conhecidos no âmbito do bloco ou da instrução em causa.

1.2 Se existirem anotac¸˜oes em trincos (da forma li ::Lock(Mi1,Mi2), Mi1

e Mi2 são conjuntos concretos que contêm trincos do programa, podendo estes serem vazios), então gerar as restrições: Li1 = Mi1

e Li2 = Mi2, em que Li1 e Li2 est˜ao associados ao trinco li. // Segunda passagem

2. Analisar cada bloco do programa:

2.1 Se a instrução é um salto condicional sobre o trinco li (da forma

if r==0 jump v) com v do tipo {...} requires G, então gerar a restrição: G < li.

2.2 Se a instrução inclui a aplicação de um trinco li a um valor v

(da forma v[ li ]), em que o tipo de v é ∀m::Lock.t, e m está associado aos conjuntos Li1 e Li2, então gerar as restrições:

Li1 < li < Li2.

2.3 Se a instrução é um salto (da forma jump v) ou o lançamento de um fio de execução (da forma fork v), com v do tipo

{r1: t1 ,..., rn: tn} requires G, comparar os tipos ti que são da forma ∀li ::Lock.ui, com os tipos dos registos correspondentes conhecidos até ao momento (da forma ∀mi ::Lock.si). Se li está associado aos conjuntos Li1 e Li2 e mi aos conjuntos Mi1 e Mi2, então gerar as restrições: Li1 = Mi1, Li2 = Mi2.

3. Resolver as restric¸˜oes recolhidas usando um SMT

Figura 4.2: Algoritmo para colecionar restric¸˜oes

pois o trinco e encontra-se em âmbito. Estes dois exemplos são referentes à al´ınea 1.1 do algoritmo. Como o exemplo da figura 4.1 está parcialmente anotado, a regra 1.2 pode ser aplicada diversas vezes no mesmo. Por exemplo, na linha 5 (g3::Lock({g1,g2},{})) são adicionadas as restriçõesL4 = {g1, g2}eL5 = {}, em queL4eL5são as variáveis associa-das ao trincog3. A tabela 4.1 apresenta todas as restrições geradas na primeira passagem do algoritmo.

Na segunda passagem o algoritmo processa cada bloco de código e comporta-se de três formas distintas consoante se trate de um teste (2.1), da instanciação de um valor polimórfico (2.2) ou de uma instrução de salto ou de lançamento de um fio de execução (2.3). Em relação a (2.1), a recolha de restrições ocorre na instrução if. Neste ponto do programa ficamos com a indicação de que os trincos já fechados têm de ser menores do que o trinco que está a tentar fechar-se. Esta regra pode ser aplicada em duas situações no

(39)

Linha Restric¸˜oes Al´ınea 3 L0 < g1 < L1,L0⊆ ∅ eL1⊆ ∅ 1.1 4 L2 < g2 < L3,L2⊆ {g1} eL3⊆ {g1} 1.1 L2 = {g1}eL3 = {} 1.2 5 L4 < g3 < L5,L4⊆ {g1, g2} eL5⊆ {g1, g2} 1.1 L4 = {g1, g2}eL5 = {} 1.2 14, 15 L6 < e < L7,L6⊆ ∅,L7⊆ ∅,L8 < d < L9,L8⊆ {e},L9⊆ {e}, 1.1 L10 < l < L11,L10⊆ {e, d} eL11⊆ {e, d} L6 = {},L7 = {},L10 = {e}eL11 = {} 1.2 22 L12 < e1 < L13,L12⊆ ∅,L13⊆ ∅,L14 < d1 < L15,L14⊆ {e1}, e 1.1 L15⊆ {e1} L12 = {},L13 = {},L14 = {e1}eL15 = {} 1.2 29 L16 < e2 < L17,L16⊆ ∅,L17⊆ ∅,L18 < d2 < L19,L18⊆ {e2}, e 1.1 L19⊆ {e2} L16 = {},L17 = {},L18 = {}eL19 = {} 1.2

Tabela 4.1: Restric¸˜oes geradas durante a primeira passagem do algoritmo

exemplo da figura 4.1. Na linha 18 pretende-se obter o trincoesem que tenha sido fechado qualquer outro trinco anteriormente. Na linha 25 pretende-se obter o trinco d1tendo já o trincoe1fechado (cf. requires {e1}na assinatura do bloco de código na linha 22). As restrições adicionadas são, respetivamente,{} < ee{e1} < d1.

Em relação à aplicação de valores (2.2) a restrição adicionada regista o facto do trinco li respeitar a ordem do fecho dos trincos associado am, ou seja, ser fechado depois dos trincos denotados porLi1e antes dos deLi2. Esta regra pode ser aplicada por diversas vezes no exemplo que apresentamos. Por exemplo, na linha 6 (r6:=levantarGarfoDireito [g1]) são adicionadas as restriçõesL12 < g1 < L13, em queL12eL13são as variáveis associadas ao trinco polimórficoe1declarado na linha 21. A tabela 4.2 contém todas as restrições geradas de acordo com esta regra, assinaladas por (2.2).

O tratamento das instruções jumpefork (2.3) é mais complicado porque há que de-terminar o tipo dos registos antes da execução destas instruções, que é calculado pelo sistema de tipos. Vamos ilustrar a aplicação desta regra à linha 7. O tipo dos registos relevantes para o lançamento do fio de execução são:

• r1:lock g1; • r2:lock g2;

• r6:∀ d1::Lock.{r1:lock g1, r2: lock d1} requires {g1}.

Tanto o registo r1 como o registo r2 não são do tipo universal, ou seja, não contêm declarações de trincos polimórficos. Neste caso, o que é relevante nas instruções fork

ejump é se os tipos dos registos, antes da execução destas instruções, são subtipos dos tipos dos registos para onde é efetuado o salto ou o lançamento do novo fio de execução.

(40)

Linha Restric¸˜oes Al´ınea 6, 8, 10 L12 < g1 < L13,L12 < g2 < L13eL12 < g3 < L13 2.2 7 L6 < g1 < L7,L8[g1/e] < g2 < L9[g1/e], 2.2 L10[g1/e][g2/d] = L14[g1/e1] e L11[g1/e][g2/d] = L15[g1/e1] 2.3 9 L6 < g2 < L7,L8[g2/e] < g3 < L9[g2/e], 2.2 L10[g2/e][g3/d] = L14[g2/e1] e L11[g2/e][g3/d] = L15[g2/e1] 2.3 11 L6 < g3 < L7,L8[g3/e] < g1 < L9[g3/e], 2.2 L10[g3/e][g1/d] = L14[g3/e1] e L11[g3/e][g1/d] = L15[g3/e1] 2.3 18 L10 < d < L11e{} < e 2.2, 2.1 19 L6 < e < L7,L8[e/e] < d < L9[e/e], 2.2

L10[e/e][d/d] = L10[e/e]eL11[e/e][d/d] = L11[e/e] 2.3 25 L16 < e1 < L17, L18[e1/e2] < d1 < L19[e1/e2] e {e1} < d1 2.2, 2.1 26 L12 < e1 < L13eL14[e1/e1] < d1 < L15[e1/e1] 2.2 32 L12 < e2 < L13 2.2 33 L6 < e2 < L7,L8[e2/e] < d2 < L9[e2/e], 2.2 L10[e2/e][d2/d] = L14[e2/e1] e L11[e2/e][d2/d] = L15[e2/e1] 2.3

Tabela 4.2: Restric¸˜oes geradas durante a segunda passagem do algoritmo

Todavia, o tipo que considera as variáveis de conjuntos é o tipo universal. Um tipo univer-sal (∀ l1 :: Lock(L0, L1).t) é subtipo de outro (∀ m1::Lock(M0, M1).t) quando as variáveis de conjuntos menor (L0) e maior (L1) do trinco (l1) são iguais às variáveis de conjuntos me-nor (M0) e maior (M1) do trinco (m1). Neste caso, o único registo que é do tipo universal é or6. Com isto, o tipo do registor6delevantarGarfoEsquerdo, após a instanciação porg1e

g2ér6:∀ l ::Lock.{r1:lock g1, r2: lock l } requires {g1}há que gerar as restriçõesL10[g1/e] [g2/d]=L14[g1/e1]eL11[g1/e][g2/d]=L15[g1/e1], em queL10eL11são as variáveis associadas ao trinco polimórfico l do blocolevantarGarfoEsquerdo e L14e L15 são as associadas ao trinco polimórficod1do bloco levantarGarfoDireito.

Por último, (3) as restrições recolhidas são passadas a um SMT que afere da sua consistência. Caso sejam consistentes, o SMT indica um modelo que instancia cada um dos conjuntos associados aos trincos, obtendo deste modo uma anotação válida; caso contrário, o SMT responde negativamente e o programa não tem qualquer anotação poss´ıvel. No caso de programas completamente anotados, o SMT não vai procurar obter conjuntos para as variáveis de conjuntos mas, no caso de programas em que não exis-tam anotações, o SMT vai procurar obter conjuntos para as variáveis de conjuntos. Ou-tra situação que pode ocorrer é ter um programa parcialmente anotado (exemplo da fi-gura 4.1) e, neste caso, o SMT vai procurar obter conjuntos para as variáveis de conjuntos cujo os trincos não tenham anotações. No caso de os trincos estarem anotados, o SMT

(41)

n˜ao vai procurar obter conjuntos para as vari´aveis de conjuntos desses trincos.

Um resolvedor SMT consegue determinar os conjuntos (Li), porque os programas MIL declaram um conjunto finito de trincos que pode ser determinado em tempo de compilação. Portanto, os conjuntos (Li) que pretendemos determinar são finitos e defi-nidos sobre um conjunto de trincos também finito.

(42)

(43)

Implementação da Máquina Virtual

Neste cap´ıtulo damos conta das tecnologias sobre as quais o analisador semântico estático e a máquina virtual do MIL são constru´ıdos (secção 5.1), apresentamos a sua arqui-tetura geral e funcionamento (secção 5.2), distinguindo entre as fases de análise e de interpretação (secção 5.3 e secção 5.4).

5.1 Tecnologias utilizadas para a construção da máquina

virtual do MIL

A máquina virtual MIL aceita como entrada um ficheiro . mil com o código fonte. O conteúdo do ficheiro é analisado de acordo com a especificação da gramática MIL, é feita a análise semântica estática e após a análise, a máquina virtual interpreta o fi-cheiro. A máquina virtual MIL é implementada em SableCC e Java. O SableCC é usado para gerar as classes Java que procedem à verificação léxica e sintática, enquanto que a análise semântica e interpretação é programada em Java. O resolvedor SMT usado para a verificação das restrições é o Z3.

5.1.1 SableCC

O SableCC [16] é uma ferramenta que gera um analisador léxico e sintático em Java a partir de um ficheiro que contém a especificação da gramática, simplificando a escrita de compiladores e interpretadores, pois gera um conjunto de classes Java, as quais contêm os analisadores léxicos e sintáticos. O resultado da análise sintática é uma árvore sintática abstrata (AST) que representa o programa.

O SableCC oferece as seguintes funcionalidades: análise léxica e sintática do pro-grama de entrada; construção automática de uma AST do propro-grama fonte (a ser com-pilado) e criação de visitantes para percorrer a AST, de acordo com o padrão de dese-nho visitante apresentado em GoF [18]. Este padrão separa as estruturas de dados da implementação, ou seja, permite fazer operações sobre a estrutura. Através do uso deste

(44)

padrão é poss´ıvel adicionar visitantes, para implementar as várias fases do analisador semântico e do interpretador.

5.1.2 Z3

O Z3 [13] é um resolvedor SMT (Satisfiability Modulo Theories) eficiente, sendo o estado de arte dos provadores de teoremas, desenvolvido pela Microsoft Research. Este resolve-dor permite verificar a consistência de fórmulas lógicas sobre uma ou várias teorias. As teorias que suporta são as seguintes: aritmética de números inteiros e reais, vetores de bits de tamanho fixo, matrizes, funções não interpretadas e quantificadores.

O Z3 aceita como entrada um ficheiro que contém uma sequência de comandos. É através destes comandos que o Z3 determina se as fórmulas lógicas introduzidas são sa-tisfaz´ıveis. Internamente, o Z3 mantém uma pilha que armazena as fórmulas e declarações de cada programa.

Para verificar a consistência das fórmulas são usados dois comandos: o assert e o

check−sat. O primeiro acrescenta uma fórmula à pilha interna do Z3. O segundo deter-mina se as fórmulas que se encontram na pilha são consistentes. Em caso afirmativo o Z3, devolve sat; caso contrário, devolve unsat. Um conjunto de fórmulas é consistente se existe uma interpretação que faz com que todas as fórmulas sejam verdadeiras [17]. No caso de um conjunto de fórmulas ser consistente, o Z3 tem a capacidade de produzir o modelo que satisfaz as fórmulas.

A teoria usada para inferir as anotações definidas no cap´ıtulo 4 foi a de vetores de bits. Através dos vetores de bits representamos os trincos e as variáveis de conjuntos. Os trincos são conjuntos singulares e, é atribu´ıdo um bit diferente para representar cada trinco do programa. As variáveis de conjuntos são expressas como conjuntos de trincos, isto é, como cada trinco é representado por um bit diferente, facilmente determinamos quais os trincos que o conjunto contém. Assim, a partir desta teoria, é poss´ıvel encontrar conjuntos de bits que satisfaçam as restrições passadas ao Z3.

5.2 Arquitetura

A arquitetura da máquina virtual do MIL está dividida em duas fases: fase de análise e fase de interpretação. A fase de análise verifica o código fonte, onde a estrutura e significado do programa são reconhecidos. Esta fase está dividida em três etapas: léxica, sintática e semântica estática. A fase de interpretação efetua a execução do programa MIL.

A figura 5.1 apresenta o modo como a máquina virtual do MIL está organizada. As conexões entre componentes (setas tracejadas) representam o fluxo de controlo.

O componenteLexer é o responsável pela análise léxica. É executado a partir do com-ponenteParser(componente responsável pela análise sintática), quando este necessita de obter o próximo s´ımbolo. Finda a análise léxica e sintática sem erros o controlo é passado