Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

163

Transcript of Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

Page 1: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 1/162

Page 2: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 2/162

Page 3: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 3/162

Page 4: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 4/162

Page 5: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 5/162

Para meus pais, Stelio e Henrriete.

Page 6: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 6/162

Agradecimentos

Quero agradecer, em primeiro lugar, à minha esposa, Karina. Sem o seu apoio

incondicional, não teria ido tão longe. Agradeço também à minha filha, Alice. Sua chegada,

no início desta pesquisa, encheu-nos de alegria.

Diversos outros agradecimentos são devidos. Ao meu pai, Stelio, que me apresentou

ao computador e, ainda mais importante, ao violão, quando eu ainda era criança. À minha

mãe, Henrriete, que foi minha primeira professora de Matemática e, portanto, de Ciência

da Computação. À minha irmã Stella, que deu, por mim, o primeiro passo para que esta

pesquisa fosse possível. À minha sogra Tânia, que, assim como meus pais, nos ajudou acuidar de Alice.

Ao meu amigo e, agora, orientador, Silvio. Quase duas décadas depois de nossa

primeira colaboração, seu entusiasmo continua sendo uma poderosa força motriz para

mim. Aos professores Kiev e Nelson, cuja participação foi fundamental para a publicação

de alguns dos resultados alcançados nesta pesquisa. Ao professor Airton, que, com muita

paciência, me ensinou Análise Real.

Aos meus grandes amigos Fábio, Idevan, Celso e Humberto. Esta pesquisa é,

também, fruto de tudo o que aprendemos juntos na NEWStorm e na Pitang.

Por fim, gostaria de agradecer ao Banco Central do Brasil, que patrocinou esta

pesquisa, e aos colegas com quem trabalho, os quais assumiram minhas funções durante

minha ausência.

Page 7: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 7/162

“This is the springtime of my loving 

The second season I am to know” 

(Page - Plant, The Rain Song)

Page 8: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 8/162

Resumo

ORMs (Object-Relational Mappers) são bastante populares porque eles reduzem o esforço

de desenvolvimento de camadas de acesso a dados ao permitir, entre outras coisas, que

sistemas manipulem objetos transientes e persistentes de maneira similar. Em particular,

ORMs permitem que sistemas naveguem por objetos de ambos os tipos exatamente

da mesma maneira. Infelizmente, entretanto, navegar por objetos persistentes é muito

mais lento do que navegar por objetos transientes. Para atenuar este problema, ORMs

pré-carregam objetos executando consultas SQL (Structured Query Language) que, no

lugar de carregar os atributos de um único objeto, tal como ocorre quando objetos são

carregados sob demanda, carregam os atributos de vários objetos. Em muitos casos, estas

consultas podem ser executadas concorrentemente. Entretanto, a maioria dos ORMsexecuta consultas apenas sequencialmente.

Esta pesquisa visa aumentar o desempenho de sistemas baseados em ORMs. Para tanto,

ela define uma DSL (Domain-Specific Language) de especificação de navegações por objetos

chamada  Litoral. Também integra esta pesquisa o projeto e a implementação de um

interpretador de especificações  Litoral. O interpretador navega por objetos transientes

(aqueles que existem apenas na memória primária) e persistentes (aqueles que armazenados

em um banco de dados relacional) e pré-carrega os do segundo tipo executando consultassequencialmente ou concorrentemente.

A estratégia desta pesquisa foi avaliada com os benchmarks sintéticos  Emeio  e OO7,

desenvolvidos, respectivamente, no contexto desta pesquisa e por terceiros. No primeiro,

pré-carregar objetos executando consultas concorrentemente aumentou a velocidade de

execução em até 323,6%. No segundo, o aumento foi de até 245,7%. Os benchmarks

também foram implementados com os ORMs Hibernate e EcliseLink JPA, os quais

aderem à especificação JPA (Java Persistence Architecture). O primeiro foi escolhido

por ser bastante popular. O segundo foi escolhido por ser a implementação de referência

desta especificação. As implementações baseadas no Hibernate e EclipseLink JPA foram

significativamente otimizadas. Entretanto, em todos os cenários de  Emeio e OO7 que

oferecem oportunidades para pré-carregar objetos executando consultas concorrentemente,

o desempenho delas foi inferior ao da implementação baseada no interpretador de  Litoral.

Palavras-chaves: Mapeamento objeto-relacional. Pré-carregamento. Concorrência.

Page 9: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 9/162

Abstract

ORMs (Object-Relational Mappers) are quite popular because they reduce the effort of 

developing data access layers by allowing, among other things, systems manipulate transient

and persistent objects in similar ways. In particular, ORMs allow systems navigate through

objects of both types exactly the same way. Unfortunately, however, navigating through

persistent objects is much slower than navigating through transient ones. To alleviate this

problem, ORMs prefetch objects executing SQL (Structured Query Language) queries

that fetch the attributes of multiple objects. In many cases, these queries can be executed

concurrently. However, most ORMs execute queries sequentially only.

In this research, we aim to increase the performance of ORM based systems. To thisend, we define a DSL (Domain-Specific Language) for specifying navigations through

objects called  Litoral. We also implement a  Litoral interpreter that navigates through

transient (objects that exist only in the primary memory) and persistent objects (objects

stored in a relational database) and prefetches the second type with queries executed

sequentially or concurrently.

We evaluated our strategy with the synthetic benchmarks  Emeio and OO7. In the first

one, prefetching objects with queries concurrently executed increased execution speed upto 323.6%. In the second one, the increase was up to 245.7%. We also implemented the

benchmarks with the Hibernate and EcliseLink JPA ORMs, which adhere to the JPA (Java

Persistence Architecture) specification. We chose the first one because it is quite popular

and the second one because it is the reference implementation of JPA. We optimized

the implementations based on Hibernate and EclipseLink JPA extensively. However, in

all scenarios of   Emeio   and OO7 that offer opportunities for prefetching objects with

queries concurrently executed, their performance was inferior to the performance of the

implementations based on the  Litoral interpreter.

Keywords: Object-relational mapping. Prefetching. Concurrency.

Page 10: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 10/162

Lista de ilustrações

Figura 1 – Trecho de código Java que navega por objetos. . . . . . . . . . . . . . . 17

Figura 2 –   Especificação  Litoral que declara navegações de mensagens para seus

remetentes e destinatários.   . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figura 3 – Trecho de código Java que pré-carrega objetos com o interpretador de

Litoral.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figura 4 – Trecho de código Java que requisita objetos especificando o predicado

que eles devem satisfazer.   . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figura 5 –  Consultas SQL que ORMs executam para carregar sob demanda os

atributos de mensagens manipulados pelo trecho de código da Figura 4.   26Figura 6 –   Consulta SQL que pré-carrega todos os atributos do primeiro tipo de

uma mensagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figura 7 –  Consulta SQL que pré-carrega todos os atributos do tipo I de uma

mensagem e, através de uma junção, também seu remetente.   . . . . . . 27

Figura 8 – Consulta SQL que pré-carrega todos os atributos de uma mensagem.   . 29

Figura 9 – Consultas que pré-carregam os destinatários e os remetentes de várias

mensagens através do operador in de SQL.   . . . . . . . . . . . . . . . . 29

Figura 10 –  Trecho de código Java que informa a ORMs compatíveis com a especifi-cação JPA quais objetos eles devem pré-carregar.   . . . . . . . . . . . . 30

Figura 11 – Método Java que carrega as mensagens enviadas por um usuário.   . . . 33

Figura 12 –  Método Java que carrega as mensagens enviadas por um usuário e

pré-carrega seus remetentes.   . . . . . . . . . . . . . . . . . . . . . . . . 33

Figura 13 – Gramática de  Litoral em notação EBNF e em diagramas de sintaxe.   34

Figura 14 – Trecho de código Java que navega por objetos.  . . . . . . . . . . . . . . 35

Figura 15 – Especificação  Litoral que navega através de um único atributo.   . . . 36

Figura 16 –  Geração da especificação da Figura 15 a partir da gramática de  Litoral.   36

Figura 17 – Especificação  Litoral que navega através de coleções de objetos.   . . . 36

Figura 18 – Especificação  Litoral que navega através de mais de um atributo.   . . 37

Figura 19 –  Geração da especificação da Figura 18 a partir da gramática de  Litoral.   37

Figura 20 – Especificação  Litoral que navega por um único atributo.   . . . . . . . 37

Figura 21 – Especificação  Litoral que navega indiretamente.  . . . . . . . . . . . . 38

Figura 22 – Especificação  Litoral que encadeia navegações indiretas.   . . . . . . . 38

Figura 23 – Especificação  Litoral que replica uma navegação.   . . . . . . . . . . . 39

Figura 24 – Especificação  Litoral que define uma travessia.   . . . . . . . . . . . . 39

Figura 25 –  Geração da especificação da Figura 24 a partir da gramática de  Litoral.   40Figura 26 – Especificação  Litoral que define uma travessia recursiva.   . . . . . . . 41

Figura 27 – Representação de classes e objetos no interpretador definidor.   . . . . . 42

Page 11: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 11/162

Figura 28 – Criação de classes no interpretador definidor.   . . . . . . . . . . . . . . 43

Figura 29 – Representação de especificações  Litoral no interpretador definidor.   . 43

Figura 30 – Criação de uma especificação  Litoral no interpretador definidor.  . . . 44

Figura 31 – Analisador semântico.   . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 31 – Analisador semântico - continuação   . . . . . . . . . . . . . . . . . . . . 46

Figura 31 – Analisador semântico - continuação.   . . . . . . . . . . . . . . . . . . . 47

Figura 31 – Analisador semântico - continuação.   . . . . . . . . . . . . . . . . . . . 48

Figura 32 –   Teorema que assegura que o analisador semântico do interpretador

definidor sempre é capaz de validar especificações  Litoral  em um

número finito de recursões. . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figura 33 – Interpretador definidor.   . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Figura 33 – Interpretador definidor - continuação.  . . . . . . . . . . . . . . . . . . . 52

Figura 33 – Interpretador definidor - continuação.  . . . . . . . . . . . . . . . . . . . 53

Figura 34 – Função filter que impede navegações.   . . . . . . . . . . . . . . . . . . . 54

Figura 35 – Semântica 1.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Figura 36 – Especificação  Litoral que entra em recursão infinita na semântica 1. . 55

Figura 37 – Mensagem que se auto-referencia.   . . . . . . . . . . . . . . . . . . . . . 55

Figura 38 – Semântica 2.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figura 39 – Teorema que assegura que, sob a semântica 2, especificações  Litoral

não entram em recursão infinita.   . . . . . . . . . . . . . . . . . . . . . 57

Figura 40 –  Programa  Litoral que especifica navegações que não são realizadasna semântica 2.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figura 41 –   Especificação  Litoral que permuta os passos de uma outra especifi-

cação e, na semântica 2, navega por objetos pelos quais a original não

navega.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Figura 42 – Semântica 3.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Figura 43 – Cálculo de   b2 − 4ac compondo invocações de métodos.   . . . . . . . . . 63

Figura 44 – Cálculo de   b2 − 4ac com funções assíncronas. . . . . . . . . . . . . . . . 64

Figura 45 –  Estratégia de  Afluentes  para combinar as vantagens de funçõessíncronas e assíncronas.   . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figura 46 – Interfaces ISyncFn0, ISyncFn1 e ISyncFn2.   . . . . . . . . . . . . . . . . 66

Figura 47 – Cálculo de  b2 − 4ac compondo invocações de funções síncronas.   . . . . 66

Figura 48 – Interface ICallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figura 49 – Interfaces IAsyncFn0, IAsyncFn1 e IAsyncFn2. . . . . . . . . . . . . . . 67

Figura 50 – Funções  sub e  mul definidas com as interfaces IAsyncFn2.   . . . . . . . 67

Figura 51 – Interface IEval.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Figura 52 – Interfaces IEval0 e IEval1.   . . . . . . . . . . . . . . . . . . . . . . . . . 68Figura 53 – Cálculo de  b2 − 4ac compondo invocações de funções síncronas.   . . . . 69

Page 12: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 12/162

Figura 54 – Cálculo de  b2 − 4ac compondo invocações de funções síncronas e assín-

cronas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Figura 55 – Processo de avaliação de  b2 − 4ac.  . . . . . . . . . . . . . . . . . . . . . 69

Figura 56 – Cálculo do somatório dos preços dos produtos de uma lista compondoinvocações de funções síncronas. . . . . . . . . . . . . . . . . . . . . . . 71

Figura 57 – Cálculo do somatório dos preços dos produtos de uma lista compondo

avaliadores de funções assíncronas e de funções sobre listas.   . . . . . . 72

Figura 58 – Interface IEvalHolder.   . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Figura 59 – Proxy que implementa a interface IEvalHolder.   . . . . . . . . . . . . . 73

Figura 60 – Interface IPrefetcher.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Figura 61 – Trecho de código Java que usa o interpretador de  Litoral.   . . . . . . 74

Figura 62 – Gramática de  Litoral na metalinguagem do ANTLR.   . . . . . . . . . 75

Figura 63 –   Especificação  Litoral cuja árvore sintática e AST são exibidas nas

figuras 64a e  64b, respectivamente.   . . . . . . . . . . . . . . . . . . . . 76

Figura 64 – Árvore sintática e AST da especificação da Figura 63   . . . . . . . . . . 77

Figura 65 – Tabela de símbolos da especificação  Litoral da Figura 63.   . . . . . . 78

Figura 66 – Interpretação de especificações  Litoral   . . . . . . . . . . . . . . . . . 80

Figura 66 – Interpretação de especificações  Litoral - Continuação   . . . . . . . . . 81

Figura 66 – Interpretação de especificações  Litoral - Continuação   . . . . . . . . . 82

Figura 67 – Especificações  Litoral que compõem o benchmark  Emeio.   . . . . . . 86

Figura 68 –  Tabelas adicionadas ao banco de dados para otimizar a implementaçãode  Emeio baseada no Hibernate.   . . . . . . . . . . . . . . . . . . . . . 87

Figura 69 – Índices criados no banco de dados de  Emeio.   . . . . . . . . . . . . . . 87

Figura 70 –  Resultado das otimizações da implementação de  Emeio  baseada no

Hibernate.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Figura 70 –  Resultado das otimizações da implementação de  Emeio  baseada no

Hibernate - continuação.   . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Figura 71 –  Tempo total de execução das implementações de  Emeio baseadas no

interpretador de  Litoral, Hibernate e EclipseLink JPA.   . . . . . . . . 91Figura 72 – Índices de OO7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Figura 73 – Especificações  Litoral que fazem parte de OO7.   . . . . . . . . . . . . 93

Figura 74 –  Resultados da otimização da implementação de  OO7 baseada no Hi-

bernate.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Figura 75 –  Tempo total de execução das implementações de  Emeio baseadas no

interpretador de  Litoral, Hibernate e EclipseLink JPA.   . . . . . . . . 95

Figura 76 –  Especificação Program Summary que declara navegações das mensagens

enviadas por um usuário para seus remetentes e destinatários.   . . . . . 96Figura 77 – Tabelas de  Emeio.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Figura 78 – Tabelas de OO7.   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Page 13: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 13/162

Lista de abreviaturas e siglas

API Application Programming Interface

AST Abstract Syntax Tree

BCB Banco Central do Brasil

CAD Computer Aided Design

CAM Computer Aided Manufacturing

CASE Computer Aided Software Engineering

DSL Domain-Specific Language

EBNF Extended Backus-Naur Form

E/S Entrada/Saída

JPA Java Persistence Architecture

JPQL Java Persistence Query Language

ORM Object-Relational Mapper

OODBMS Object-Oriented Database Management System

REST Representational State Transfer

RMI Remote Method Invocation

SGBD Sistema de Gerenciamento de Banco de Dados

SOAP Simple Object Access Protocol

SQL Structured Query Language

VLSI Very Large Scale Integration

XPath XML Path Language

XML Extensible Markup Language

Page 14: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 14/162

Sumário

1 INTRODUÇÃO   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.1 Objetivo   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   16

1.2 ORMs   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   16

1.3 Hipótese   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   17

1.4 Estratégia   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   18

1.4.1 Viabilidade   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   19

1.4.2 Generalidade   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   19

1.5 Avaliação   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   201.6 Organização   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   20

2 CONCEITOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1 Sistemas Intensivos em Processamento e em E/S . . . . . . . . . . .   22

2.2 Otimização de Sistemas Intensivos em E/S   . . . . . . . . . . . . . .   23

2.2.1 Caching   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   23

2.2.2 Agregação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   23

2.2.3 Carregamento sob Demanda e Pré-carregamento   . . . . . . . . . . . . . .   23

2.2.3.1 Pré-carregamento Informado e Especulativo   . . . . . . . . . . . . . . . . . . . .   24

2.2.4 Compressão   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   24

2.2.5 Concorrência   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   24

2.3 Carregamento sob Demanda, Pré-carregamento e Agregação em

ORMs   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   25

2.3.1 Tipos de Atributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   25

2.3.2 Carregamento de Atributos do Tipo I   . . . . . . . . . . . . . . . . . . . .   27

2.3.3 Carregamento de Atributos do Tipo II que Referenciam Objetos   . . . . . .   27

2.3.4 Carregamento de Atributos do Tipo II que Referenciam Coleções   . . . . . .   282.3.5 Pré-carregamento Informado   . . . . . . . . . . . . . . . . . . . . . . . . .   28

2.3.6 Pré-carregamento Especulativo  . . . . . . . . . . . . . . . . . . . . . . . .   30

2.4 Hipótese   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   30

3 LITORAL   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1 Requisitos   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   32

3.2 Sintaxe   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   34

3.3 Semântica Informal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   35

3.3.1 Navegando Através de um Único Atributo   . . . . . . . . . . . . . . . . . .   363.3.2 Navegando Através de mais de um Atributo   . . . . . . . . . . . . . . . . .   36

3.3.3 Navegando Indiretamente . . . . . . . . . . . . . . . . . . . . . . . . . . .   37

Page 15: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 15/162

3.3.4 Travessias   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   39

3.3.5 Travessias Recursivas   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   39

3.4 Interpretador Definidor   . . . . . . . . . . . . . . . . . . . . . . . . . .   41

3.4.1 Representação de Classes e Objetos   . . . . . . . . . . . . . . . . . . . . .   423.4.2 Representação de Especificações Litoral   . . . . . . . . . . . . . . . . .   43

3.4.3 Análise Semântica   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   43

3.4.4 Interpretação   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   50

3.4.4.1 Argumentos S, filter e s   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   53

3.4.4.2 Semântica 1   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   54

3.4.4.3 Semântica 2   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   56

3.4.4.4 Semântica 3   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   58

3.4.4.5 Escolha de uma Semântica   . . . . . . . . . . . . . . . . . . . . . . . . . . . .   60

4 INTERPRETADOR   . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.1 Afluentes   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   61

4.1.1 Modelo de Programação   . . . . . . . . . . . . . . . . . . . . . . . . . . .   62

4.1.2 Funções Síncronas   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   62

4.1.3 Funções Assíncronas   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   63

4.1.4 Avaliadores, Avaliações e Processo de Avaliação  . . . . . . . . . . . . . . .   65

4.1.5 Representando Funções Síncronas   . . . . . . . . . . . . . . . . . . . . . .   65

4.1.6 Callbacks   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   664.1.7 Representando Funções Assíncronas   . . . . . . . . . . . . . . . . . . . . .   67

4.1.8 Avaliações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   67

4.1.9 Avaliadores   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   68

4.1.10 Funções sobre Listas   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   70

4.1.11 Avaliadores de Funções sobre Listas   . . . . . . . . . . . . . . . . . . . . .   70

4.2 Projeto   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   71

4.3 Implementação   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   74

4.3.1 Análise Léxica e Sintática . . . . . . . . . . . . . . . . . . . . . . . . . . .   744.3.2 Análise Semântica   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   76

4.3.3 Interpretação   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   78

4.3.3.1 Nós que Atuam Sobre Objetos   . . . . . . . . . . . . . . . . . . . . . . . . . .   78

4.3.3.2 Nós que Atuam Sobre Listas   . . . . . . . . . . . . . . . . . . . . . . . . . . .   79

5 AVALIAÇÃO   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.1 Emeio   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   84

5.1.1 Implementação Baseada no Hibernate   . . . . . . . . . . . . . . . . . . . .   85

5.1.2 Implementação Baseada no EclipseLink JPA   . . . . . . . . . . . . . . . . .   895.1.3 Implementação Baseada no Interpretador de  Litoral   . . . . . . . . . . .   89

5.1.4 Resultados   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   90

Page 16: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 16/162

5.2 OO7   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   92

5.2.1 Implementação Baseada no Hibernate   . . . . . . . . . . . . . . . . . . . .   93

5.2.2 Implementação Baseada no EclipseLink JPA   . . . . . . . . . . . . . . . . .   94

5.2.3 Implementação Baseada no Interpretador de  Litoral   . . . . . . . . . . .   945.2.4 Resultados   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   94

6 TRABALHOS RELACIONADOS  . . . . . . . . . . . . . . . . . . . . 96

6.1 Program Summaries   . . . . . . . . . . . . . . . . . . . . . . . . . . . .   96

6.2 Scalpel   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   98

6.3 AutoFetch   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   99

6.4 Outros Trabalhos sobre Pré-carregamento Especulativo   . . . . . . .  100

7 CONCLUSÃO   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.1 Contribuições   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  101

7.2 Trabalhos Futuros   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Referências   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

APÊNDICE A – EMEIO   . . . . . . . . . . . . . . . . . . . . . . . . 109

A.1 Classes   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  109

A.2 Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  111

APÊNDICE B – OO7  . . . . . . . . . . . . . . . . . . . . . . . . . . 112

B.1 Classes   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  112

B.2 Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  114

APÊNDICE C – DEMONSTRAÇÕES . . . . . . . . . . . . . . . . . 115

C.1 Seq   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  115

C.2 NatSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  115

C.3 ListSeq   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  118

C.4 Lim   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  120

C.5 ListOptionSeq  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  121

C.6 Sublist   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

C.7 LitoralFacts   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

C.8 AnalyzeSpecFacts   . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

C.9 InterpretSpecFacts   . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  151

Page 17: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 17/162

16

1 Introdução

Sistemas computacionais são pervasivos em nossa sociedade. Em boa parte, isto se

deve à maior eficácia e eficiência observadas quando a sociedade executa diferentes processos

de negócio apoiada por tais sistemas. No Brasil, por exemplo, o uso da computação permite

que eleitores conheçam os resultados de eleições apenas algumas horas depois de encerradas

as votações. Antes das urnas eletrônicas, a apuração de votos durava vários dias. Além disto,

como votos eram computados manualmente, esta etapa do processo eleitoral estava mais

sujeita a erros e fraudes. A otimização de sistemas computacionais, portanto, contribui,

em última análise, para uma sociedade mais eficaz e eficiente.

Muitos sistemas sobre os quais a sociedade se apóia são construídos em linguagens

orientadas a objetos e manipulam dados armazenados em bancos de dados relacionais

através de ORMs (Object-Relational Mappers). No BCB (Banco Central do Brasil), por

exemplo, existe a diretriz de que todos os sistemas devem ser desenvolvidos em linguagens

orientadas a objetos, devem armazenar dados em bancos relacionais e, por fim, devem

interagir com estes bancos de dados através de ORMs. Esta diretriz se aplica não só aos

sistemas corporativos (utilizados por mais de um departamento do BCB) como também

aos departamentais (utilizados por um único departamento), independentemente destes

sistemas serem desenvolvidos pelo próprio BCB ou contratados a terceiros.

1.1 Objetivo

Dada a sua importância para a sociedade, esta pesquisa visa aumentar o desempenho

de sistemas baseados em ORMs.

1.2 ORMsORMs são populares porque eles reduzem o esforço de desenvolvimento de camadas

de acesso a dados ao permitir, entre outras coisas, que sistemas manipulem objetos

transientes e persistentes de maneira similar. Em particular, ORMs permitem que sistemas

naveguem por objetos de ambos os tipos exatamente da mesma maneira. Por exemplo, o

trecho de código Java (GOSLING et al., 2014) da Figura 1 navega de mensagens para seus

remetentes (linha 4) e destinatários (linha 5), não importando se estes objetos existem

apenas na memória primária (ou seja, são transientes) ou se um banco de dados relacional

os armazena (ou seja, são persistentes). Infelizmente, este trecho de código é muito maislento no segundo caso porque, para que ele navegue de uma mensagem para um objeto

destino, ORMs precisam primeiro carregar o objeto destino do banco de dados.

Page 18: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 18/162

Capítulo 1. Introdução   17

1   List <Message> messages = getMessages ( ) ;

2   f o r   ( Mes sa ge m e ss a ge : m e s sa g e s ) {

3   print Messa ge ( message ) ;

4   pr int User ( message . getSender ( ) ) ;

5   f o r   ( U ser r e c i p i e n t : m es sa ge . g e t R e c i pi e n t s ( ) ) {6   p r i n tU s e r ( r e c i p i e n t ) ;

7   }

8   }

Figura 1 – Trecho de código Java que navega por objetos.

ORMs atenuam este problema pré-carregando (prefetching) objetos, ou seja, carre-

gando objetos antes de um sistema navegar por eles. O pré-carregamento propriamente

dito não reduz o tempo   tc  que ORMs levam para carregar objetos, mas dá a ORMs achance de pré-carregarem vários objetos executando uma única consulta SQL (Structured

Query Language) (EISENBERG et al., 2004). Pré-carregar os mesmos objetos executando

menos consultas é o que realmente reduz  tc, pois isto diminui a incidência das latências

dos canais de comunicação entre ORMs e bancos de dados sobre   tc (BERNSTEIN; PAL;

SHUTT, 2000).

Voltando ao exemplo da Figura 1: sem pré-carregamento, ORMs executam duas

consultas para cada execução das linhas 4–5. A primeira carrega o remetente de uma

mensagem sob demanda. A segunda carrega seus destinatários sob demanda. Portanto, se ométodo   getMessages retorna n mensagens, então ORMs executam 2n consultas. Por outro

lado, com pré-carregamento, ORMs podem pré-carregar remetentes e destinatários de todas

as mensagens executando apenas 2 consultas quando a linha 1 é executada, não importando

quantas mensagens   getMessages   retorna, reduzindo assim  tc significativamente.

Como as consultas que pré-carregam remetentes e destinatários são independentes,

elas podem ser executadas concorrentemente. Entretanto, a maioria dos ORMs executa

consultas apenas sequencialmente.

1.3 Hipótese

Esta pesquisa parte da hipótese de que o pré-carregamento, em muitos casos,

também dá a ORMs a chance de executar consultas concorrentemente e que, combinando

esta otimização com consultas que carregam vários objetos, ORMs podem reduzir  tc ainda

mais.

Page 19: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 19/162

Capítulo 1. Introdução   18

1   [ s e nd e r r e c i p i e n t s ]

Figura 2 – Especificação  Litoral que declara navegações de mensagens para seus reme-tentes e destinatários.

1   List <Message> messages = getMessages ( ) ;

2

3   S t r i n g s p ec = " [ s e n d er r e c i p i e n t s ] " ;

4   IPr e fet cher <List <Message>> pre fe tc he r =

5   new   Pre fetc herI mpl <List <Message>>(spec ) {};

6   pr e f et ch er . pre fet ch ( messages ) ;

7

8   f o r   ( Mes sa ge m e ss a ge : m e s sa g e s ) {   / ∗   . . .   ∗/   }

Figura 3 – Trecho de código Java que pré-carrega objetos com o interpretador de  Litoral.

1.4 Estratégia

Esta pesquisa define uma DSL (Domain-Specific Language) (DEURSEN; KLINT;

VISSER, 2000) de especificação de navegações por objetos chamada  Litoral. A Figura

2, por exemplo, exibe uma especificação  Litoral que declara navegações de mensagens

para seus remetentes e destinatários.

Também faz parte desta pesquisa o projeto e a implementação de um interpretadorque executa especificações  Litoral. O interpretador navega por objetos transientes e

persistentes e pré-carrega os do segundo tipo executando consultas concorrentemente. O

interpretador foi projetado de forma a absorver todas as questões relativas à concorrência,

delegando a ORMs questões relativas à interação com bancos de dados. Graças a esta

divisão de responsabilidades, qualquer ORM pode embutir o interpretador e assim pré-

carregar objetos executando consultas concorrentemente. A Figura 3, por exemplo, exibe

o trecho de código previamente exibido na Figura 1 modificado para usar o interpretador.

A linha 4 instancia o interpretador a partir da especificação   Litoral contida nalinha 3. A linha 5 executa o interpretador passando-lhe como parâmetro uma lista de

mensagens. Quando a execução da linha 5 chega ao fim, o interpretador terá pré-carregado

os remetentes e destinatários das mensagens. A grande diferença entre os trechos de código

exibidos nas Figuras 1 e 3  é que no primeiro, que não faz uso do interpretador, ORMs

pré-carregam objetos executando consultas sequencialmente, enquanto que no segundo o

interpretador pré-carrega objetos executando consultas concorrentemente.

Um aspecto positivo desta estratégia é que ela permite que programadores desen-

volvam sistemas que pré-carregam objetos executando consultas concorrentemente sem,contudo, lidar com programação concorrente, reconhecidamente difícil (NANZ; WEST;

SILVEIRA, 2013).

Page 20: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 20/162

Capítulo 1. Introdução   19

Outro aspecto que merece destaque nesta estratégia é que ela pode ser adotada

pontualmente e também a posteriori. O trecho de código da Figura 3, por exemplo, é

funcionalmente idêntico com ou sem o interpretador. A diferença nestes dois casos é apenas

não-funcional. Com o interpretador, o trecho de código é executado mais rapidamente.Portanto, pode-se identificar em códigos preexistentes os pontos que oferecem maiores

oportunidades para pré-carregar objetos executando consultas concorrentemente e adotar

o interpretador apenas nestes pontos.

1.4.1 Viabilidade

Existe um debate em torno da viabilidade de programadores especificarem navega-

ções. De um lado do debate, (IBRAHIM; COOK, 2006) argumenta que é difícil especificar

navegações corretamente. Adicionalmente, manutenções evolutivas e corretivas podeminvalidar especificações previamente válidas. Estes trabalhos propõem métodos que permi-

tam a ORMs especular quais navegações sistemas executam, eliminando a necessidade de

programadores especificarem navegações.

Do outro lado do debate, (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) defende

que programadores especialistas podem especificar navegações com relativa facilidade e

que o aumento de desempenho obtido a partir delas compensa seus custos. Uma evidência

de que esta opinião é no mínimo razoável é que ORMs bastante populares (BLAKE-

LEY et al., 2006;  ADYA et al., 2007;  CASTRO; MELNIK; ADYA, 2007;  LINSKEY;PRUD’HOMMEAUX, 2007; O’NEIL, 2008) oferecem mecanismos para que programadores

especifiquem navegações. Além disto, como os métodos de especulação são falíveis, eles

podem resultar no pré-carregamento de mais ou menos objetos do que o necessário, preju-

dicando o desempenho dos sistemas que os adotam. Portanto, pelo menos nestes casos, é

preciso um mecanismo que permita ao programador sobrepor as especulações dos métodos.

Apesar desta pesquisa se alinhar aos trabalhos que defendem que os benefícios

superam os custos, ela continuará válida mesmo que esta hipótese não se confirme. Isto

acontece porque a otimização que ela propõe, ou seja, pré-carregar objetos executandoconsultas concorrentemente, pode ser implementada a partir de navegações especificadas

automaticamente ou manualmente.

1.4.2 Generalidade

O projeto do interpretador é genérico o bastante para que ele possa delegar a

interação com o repositório de objetos não só a um ORM (caso os objetos estejam

armazenados em um banco de dados relacional), mas também a qualquer outro mecanismo

de acesso a objetos, independentemente de qual é o repositório subjacente. É possível,

por exemplo, usar o interpretador para pré-carregar concorrentemente objetos que estão

Page 21: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 21/162

Capítulo 1. Introdução   20

armazenados em um outro sistema. Basta que o último adote algum mecanismo de

computação distribuída tal como RMI (WALDO, 1998), SOAP (RYMAN, 2001), REST

(FIELDING; TAYLOR, 2002), etc. É por conta desta generalidade que a presente pesquisa

é intitulada “Otimizando Sistemas Intensivos em Entrada/Saída Através de ProgramaçãoConcorrente”.

1.5 Avaliação

A estratégia da Seção 1.4 foi avaliada com os benchmarks sintéticos (CURNOW;

WICHMANN, 1976)  Emeio, desenvolvido no contexto desta pesquisa, e OO7 (CAREY;

DEWITT; NAUGHTON, 1993; CAREY et al., 1994). No primeiro, pré-carregar objetos

executando consultas concorrentemente aumentou a velocidade de execução em até 323,6%.No segundo, o aumento foi de até 245,7%.

Os benchmarks também foram implementados com os ORMs Hibernate (O’NEIL,

2008) e EcliseLink JPA (KEITH; SCHINCARIOL, 2009), os quais aderem à especificação

JPA (Java Persistence Architecture) (GROUP, 2013). O primeiro foi escolhido por ser

bastante popular. O segundo foi escolhido por ser a implementação de referência desta

especificação (FOUNDATION, 2008). As implementações baseadas no Hibernate e Eclip-

seLink JPA foram significativamente otimizadas. Entretanto, em todos os cenários de

Emeio e OO7 que oferecem oportunidades para pré-carregar objetos executando consul-tas concorrentemente, o desempenho delas foi inferior ao da implementação baseada no

interpretador de  Litoral.

1.6 Organização

O restante desta dissertação está organizado nos seguintes capítulos:

•  o Capítulo 2 discute conceitos básicos para o entendimento desta pesquisa e, a partirdeles, justifica a hipótese da Seção 1.3;

•  o Capítulo 3 apresenta a sintaxe de  Litoral em notação EBNF (Extended Backus-

Naur Form) e sua semântica através de exemplos e de um interpretador definidor

(definitional interpreter) (REYNOLDS, 1972) desenvolvido com o assistente de provas

(GEUVERS, 2009) Coq (BERTOT; CASTÉRAN, 2004);

•   o Capítulo  4 apresenta o projeto e a implementação do interpretador de  Lito-

ral, o qual foi construído sobre o framework  Afluentes (ARAUJO et al., 2014),

desenvolvido no contexto desta pesquisa e também apresentado neste capítulo;

Page 22: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 22/162

Capítulo 1. Introdução   21

•   o Capítulo 5 apresenta os bechmarks  Emeio  e OO7 e as implementações destes

benchmarks baseadas no Hibernate, EclipseLink JPA e no interpretador de  Litoral,

comparando o desempenho destas implementações;

•   o Capítulo 6 discute trabalhos relacionados a esta pesquisa;

•  o Capítulo 7 conclui esta dissertação elencando suas contribuições e possíveis traba-

lhos futuros.

Page 23: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 23/162

22

2 Conceitos Básicos

Este capítulo discute conceitos básicos para o entendimento da presente pesquisa e,

a partir deles, justifica a hipótese da Seção 1.3.

2.1 Sistemas Intensivos em Processamento e em E/S

O tempo total  tt  que um sistema computacional leva para executar uma tarefa é

formado por duas parcelas:

1.  o tempo te/s que o processador está ocioso, esperando que operações de E/S transfiram

dados para a memória primária e secundária, respectivamente. No caso de sistemas

baseados em ORMs, esta parcela incorpora o tempo de carregamento de objetos  tc,

discutido na seção 1.2;

2. o tempo  t p que o processador está ocupado, processando os dados transferidos para

a memória primária.

A caracterização de  te/s apresentada acima é a usualmente encontrada em livros desistemas operacionais (TANENBAUM, 2008). Provavelmente ela é reminiscente de um

tempo em que operações de E/S eram realizadas apenas para transferir dados entre a

memória primária e meios de armazenamento de massa tais como fitas e discos magnéticos.

Atualmente, operações de E/S são realizadas também para outros propósitos, tais como

comunicação entre processos e em redes de computadores. Portanto, parece mais adequado

chamar esta parcela de tempo de comunicação, seja esta comunicação com uma controladora

de fita, de disco, com outro processo ou com outro computador. Esta pesquisa atribui a

te/s esta última caracterização, mais ampla.

Em muitos sistemas, uma destas parcelas domina  tt. Os sistemas nos quais  te/s é

dominante, como os que processam dados comerciais, são chamados de intensivos em E/S.

Já os sistemas nos quais  t p  é dominante, como os que realizam cálculos científicos, são

chamados de intensivos em processamento.

Dada a natureza dos sistemas intensivos em processamento, só é possível aumentar

significativamente o seu desempenho reduzindo t p. Nestes sistemas, reduções em  te/s têm

baixo impacto sobre  tt. Por exemplo, suponha que em um sistema  te/s e  t p  respondam por

20% e 80% de  tt, respectivamente. Neste caso, uma redução de 50% em  te/s reduzirá  tt emapenas 10%. Já uma redução de também 50% em  t p  reduzirá  tt em 40%.

Page 24: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 24/162

Capítulo 2. Conceitos Básicos    23

Nos sistemas intensivos em E/S, os papéis se invertem. Reduções em  t p têm baixo

impacto sobre  tt. Portanto, nestes sistemas, reduzir  te/s é a melhor estratégia quando se

deseja reduzir  tt.

2.2 Otimização de Sistemas Intensivos em E/S

Esta seção discute estratégias para aumentar o desempenho de sistemas intensivos

em E/S.

2.2.1 Caching

Caching consiste em armazenar na memória primária o resultado das operações

de entrada que um sistema executa repetidas vezes. Desta forma, quando um sistema

precisa, pela primeira vez, de um dado que não está na memória primária, uma operação

de entrada é executada. Quando o sistema precisar novamente do mesmo dado, ele já se

encontrará na memória primária, não sendo necessário efetuar uma operação de entrada

novamente.

2.2.2 Agregação

Operações de E/S exibem uma latência significativa. Ou seja, o intervalo de tempotranscorrido entre o início e o fim de uma operação de E/S não é desprezível, mesmo

quando o volume de dados transferidos é o menor possível (um bloco de um disco, por

exemplo). Agregando diversas operações de E/S em uma única operação que produz os

mesmos efeitos das operações agregadas, a latência das operações de E/S incide sobre um

sistema uma única vez ao invés de diversas vezes.

2.2.3 Carregamento sob Demanda e Pré-carregamento

Dados podem ser carregados sob demanda ou pré-carregados. No primeiro caso,eles são carregados imediatamente antes do instante  t em que um sistema os manipula.

No segundo caso, eles são carregados com alguma antecedência a  t.

O pré-carregamento propriamente dito não é uma otimização. Entretanto, por ser

necessário à agregação de operações de entrada, ele é muitas vezes confundido com a

última, esta sim uma otimização. Tal confusão é lamentável, pois, apesar de necessário, o

pré-carregamento não é suficiente para a agregação, já que é possível pré-carregar dados

executando operações de entrada que não foram agregadas.

Page 25: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 25/162

Capítulo 2. Conceitos Básicos    24

2.2.3.1 Pré-carregamento Informado e Especulativo

O pré-carregamento pode ser informado ou especulativo. No primeiro caso, é

necessário que programadores informem quais dados devem ser pré-carregados. O segundo

caso elimina esta necessidade empregando métodos que especulam quais dados sistemasmanipulam. Os métodos se baseiam em informações coletadas estática ou dinamicamente.

De maneira geral, quanto mais próximas do sistema forem as informações coletadas, mais

corretas são as especulações dos métodos.

Como os métodos de especulação são falíveis, o pré-carregamento baseado neles

pode carregar menos ou mais dados do que o necessário, reduzindo o desempenho de

sistemas. Um método que costuma falhar por excesso, por exemplo, consiste em supor que

sistemas sempre manipulam todos os dados associados a um dado inicial. Graças a métodos

imprecisos como este, o carregamento sob demanda é visto como uma otimização, pois elenunca carrega mais dados do que o necessário. É importante ressaltar, entretanto, que o

carregamento sob demanda nunca é mais rápido do que o pré-carregamento executado a

partir de informações ou especulações corretas e costuma ser significativamente mais lento

do que este pré-carregamento combinado com a agregação de operações de entrada.

2.2.4 Compressão

O tempo de execução de operações de E/S é uma função monotônica não-decrescentedo volume de dados transferidos. Portanto, comprimindo dados antes de transferi-los, reduz-

se potencialmente o tempo de execução de operações de E/S. É necessário descomprimir

os dados após transferi-los, o que aumenta  t p. Este aumento, entretanto, não costuma ser

significativo frente à redução no tempo de execução das operações de E/S, fazendo com

que o saldo final desta estratégia seja positivo.

2.2.5 Concorrência

Caching, agregação e compressão reduzem te/s otimizando as operações de E/S queum sistema executa. Uma estratégia ortogonal às anteriores para reduzir te/s consiste em

executar estas operações concorrentemente, sem atuar sobre seu desempenho. Por exemplo,

suponha que um sistema executa duas operações independentes cujos tempos de execução

são t1 e t2, respectivamente. Se o sistema executa estas operações sequencialmente, então te/sserá a soma de  t1 e  t2. Entretanto, se o sistema executa estas operações concorrentemente,

então  te/s vai variar do máximo entre  t1 e  t2 (melhor caso) à soma de  t1 e  t2 (pior caso). O

melhor caso ocorrerá se existirem os recursos necessários à execução paralela das operações.

No outro extremo, se só existirem recursos suficientes para executar uma operação de cadavez, ocorrerá o pior caso.

O exemplo anterior, apesar de bastante simples, ilustra as condições que um sistema

Page 26: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 26/162

Capítulo 2. Conceitos Básicos    25

deve satisfazer para que a execução concorrente de operações de E/S seja uma otimização

eficaz:

1. o sistema executa um número significativo de operações independentes;

2. os tempos de execução das operações são similares;

3.   existem recursos computacionais suficientes para executar as operações em paralelo.

Se a primeira condição é falsa, então existem poucas oportunidades para executar

operações de E/S em paralelo. Se a segunda condição não é verdadeira, então a diferença

entre o tempo que o processador espera pela execução sequencial e paralela das operações

não é significativo. Por fim, se a terceira condição não é satisfeita, então as operações sãoexecutadas sequencialmente mesmo quando o sistema as requisita concorrentemente.

2.3 Carregamento sob Demanda, Pré-carregamento e Agregação

em ORMs

Sistemas requisitam objetos a ORMs especificando seus identificadores, ou seja,

valores que os identificam unicamente, ou predicados que eles devem satisfazer. O trecho

de código Java da Figura 4 exemplifica o segundo tipo de requisição. A linha 1 contémuma consulta JPQL (Java Persistence Query Language) (GROUP, 2013) que especifica as

mensagens enviadas pelo usuário cujo identificador é igual a   1. As linhas 2–3 requisitam

estas mensagens a ORMs compatíveis com a especificação JPA. As seções A.1 e A.2 contêm

o código das classes que este trecho de código manipula e as tabelas que armazenam seus

objetos, respectivamente.

2.3.1 Tipos de Atributo

Objetos possuem dois tipos de atributo. O tipo I armazena informações acerca do

objeto propriamente dito. O nome de um usuário e a data de envio de uma mensagem

são exemplos deste tipo. O tipo II representa associações entre objetos. Exemplos deste

último tipo são o remetente, os destinatários e os anexos de uma mensagem.

Na maioria dos casos, sistemas requisitam objetos sem especificar quais atributos

devem ser carregados. Se ORMs carregam atributos sob demanda, então eles executam

uma consulta SQL para carregar cada atributo de cada objeto que os sistemas manipulam.

A Figura 5,  por exemplo, exibe as consultas SQL que ORMs executam para carregar sob

demanda os atributos de mensagens manipulados pelo trecho de código da Figura 4.

Page 27: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 27/162

Page 28: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 28/162

Page 29: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 29/162

Page 30: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 30/162

Page 31: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 31/162

Capítulo 2. Conceitos Básicos    30

1   S tr i n g j p q l = " s e l e c t m f r om Mes sa ge m whe re m . s e n d e r . i d = 1 " ;

2   TypedQuery<Message> query = jpa . crea teQ uer y ( jp ql , Message . c l a s s ) ;

3

4   EntityGraph<Message> spe c = manager . crea teE nti tyG rap h ( Message . c l a s s ) ;

5   spec . addSubgraph( " re ci pi en t s " ) ;6   sp ec . addSub graph ( " f i l e s " ) ;

7   query . set Hin t ( " javax . pe rs is te nc e . loadgrap h " , spec ) ;

8

9   List <Message> messages = query . get Res ul tL ist ( ) ;

10

11   f o r   ( Mes sa ge m e ss a ge : m e s sa g e s ) {   / ∗   . . .   ∗/   }

Figura 10 – Trecho de código Java que informa a ORMs compatíveis com a especificaçãoJPA quais objetos eles devem pré-carregar.

A Figura 10 exemplifica o primeiro. Ela adiciona ao trecho de código da Figura 4 as linhas

4–7. Elas requisitam a ORMs compatíveis com a especificação JPA o pré-carregamento

dos destinatários e anexos das mensagens resultantes da consulta JPQL da linha 1.

2.3.6 Pré-carregamento Especulativo

O laço da Figura 4 é bastante regular. Ele sempre navega de cada mensagem para seu

remetente, destinatários e anexos. Regularidades como esta motivaram (BERNSTEIN; PAL;SHUTT, 2000) a propor um método de especulação que consiste em ORMs armazenarem

o contexto em que eles carregaram ou pré-carregaram objetos.

O contexto de um objeto  A  é o conjunto de objetos que foi carregado ou pré-

carregado pela operação (consulta, navegação, etc.) que carregou ou pré-carregou  A.

Quando um sistema navega de  A para outro objeto  B  através de um atributo  b, ORMs

pré-carregam todos os objetos referenciados pelos objetos do contexto de  A através do

atributo  b.

Aplicando este método no trecho de código da Figura 4, ORMs pré-carregam osdestinatários e os anexos de todas as mensagens quando as linhas 12 e 17 são executadas,

respectivamente, pela primeira vez.

2.4 Hipótese

A partir das discussões e exemplos das seções anteriores, esta seção justifica a

hipótese de que o tempo que ORMs levam para pré-carregar objetos executando consultas

concorrentemente é menor do que sequencialmente.Sistemas baseados em ORMs adotam o estilo de programação exibido na Figura 4

(IBRAHIM; WIEDERMANN; COOK, 2009). Neste estilo, é comum que sistemas, exceto os

Page 32: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 32/162

Capítulo 2. Conceitos Básicos    31

mais simples, naveguem através de dois ou mais atributos do tipo II. Nestes casos, tal como

exemplificado na Subseção 2.3.5, as consultas que pré-carregam os objetos referenciados

pelos atributos são independentes.

As consultas que ORMs executam para pré-carregar objetos referenciados poratributos do tipo II são bastante simples. Como elas são compostas apenas por restrições

sobre chaves primárias e estrangeiras, seus tempos de execução costumam ser dominados

pelas latências dos canais de comunicação entre ORMs e bancos de dados (BERNSTEIN;

PAL; SHUTT, 2000). Isto faz com que estes tempos sejam similares.

Sistemas de gerenciamento de banco de dados são executados com frequência em

instalações que possuem os recursos necessários para a execução paralela de diversas

consultas. O surgimento e a popularização da computação em nuvem (ARMBRUST et al.,

2010) têm contribuído para que isto ocorra cada vez mais.

Como ORMs executam consultas através de operações de E/S, as últimas gozam

das propriedades das primeiras. Por exemplo, se duas consultas são independentes, então

as operações de E/S através das quais elas são executadas também são independentes.

Conclui-se, portanto, que, em muitos casos, ORMs pré-carregam objetos executando

operações de E/S independentes, cujos tempos de execução são similares e existem recursos

computacionais suficientes para executar estas operações em paralelo. Ou seja, o pré-

carregamento de objetos executado por ORMs satisfaz as condições discutidas na seção

2.2.5 para que a execução concorrente de operações de E/S seja uma otimização eficaz.

Page 33: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 33/162

Page 34: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 34/162

Page 35: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 35/162

Capítulo 3.   Litoral   34

(a)

(b)

Figura 13 – Gramática de  Litoral em notação EBNF e em diagramas de sintaxe.

uma única alternativa, manter as duas versões de   getMessages  no sistema, utilizandocada uma delas quando for mais apropriado.

É fácil ver que existe uma forte tensão entre desempenho e reuso de código

(IBRAHIM; COOK, 2006). O problema aqui é que a especificação de quais objetos devem

ser carregados faz parte da API (Application Programming Interface) de um ORM e,

portanto, está confinada às camadas de acesso a dados de sistemas, onde seu uso pode

ter efeitos globais devido ao reuso de código. Especificações  Litoral, por outro lado,

podem ser incorporadas aos pontos mais externos de sistemas (por exemplo, nas camadas

de apresentação), tendo, portanto, efeitos mais localizados.

3.2 Sintaxe

A figura 13 apresenta a gramática de  Litoral   em notação EBNF (Extended

Backus–Naur Form) e também através de diagramas de sintaxe. Os símbolos   s p e c i f i c a t i o n ,

t r a v e r s a l ,   path  e   s te p  são não-terminais.   ID  e os símbolos entre aspas simples são

terminais.   s p e c i f i c a t i o n  é o símbolo inicial. A expressão regular   [ a−zA−Z ] [ a−zA−Z0−9]∗

gera   ID, ou seja, um   ID  é formado por uma letra seguida de outras letras ou números.

Page 36: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 36/162

Capítulo 3.   Litoral   35

1   void   pr in tMessage ( Message message) {

2   pr in tl n ( message . getDate ( ) ) ;

3   p r i n t l n ( m es s ag e . g e tS u b j e c t ( ) ) ;

4   pr in tl n ( message . getBody ( ) ) ;

5

6   pr int User ( message . getSender ( ) ) ;

7

8   f o r   ( U ser r e c i p i e n t : m es sa ge . g e t R e c i pi e n t s ( ) ) {

9   p r i n tU s e r ( r e c i p i e n t ) ;

10   }

11

12   f o r   ( Fi le attachment : message . getAttachments () ) {

13   pr in tl n ( attachment . getName ( ) ) ;

14

15   printMediaType( attachment . getMediaType ( ) ) ;16   }

17

18   f o r   ( M e ss ag e r e p l y : m es sa ge . g e t R e p l i e s ( ) ) {

19   pr intMessage ( repl y ) ;

20   }

21   }

22

23   void   p r i n tU s e r ( U se r u s e r ) {

24   pr in tl n ( use r . getName ( ) ) ;

25

26   p r i n t F i l e ( u s e r . g e t P i c t u r e ( ) ) ;

27   }

28

29   void   p r i n t F i l e ( F i l e f i l e ) {

30   pr in tl n ( f i l e . getName ( ) ) ;

31

32   printMediaTyp e ( f i l e . getMediaType ( ) ) ;

33   }

34

35   void   printMediaType (MediaType mediaType) {36   pr in tl n (mediaType . getType ( ) ) ;

37   pr in tl n (mediaType . getSubtype ( ) ) ;

38   }

Figura 14 – Trecho de código Java que navega por objetos.

3.3 Semântica Informal

Esta seção se inspira em (MEYEROVICH et al., 2009) e apresenta a semântica deLitoral informalmente através de vários exemplos que, progressivamente, especificam as

navegações que o trecho de código Java exibido na Figura 14 executa.

Page 37: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 37/162

Capítulo 3.   Litoral   36

1   s e n d e r

Figura 15 – Especificação  Litoral que navega através de um único atributo.

1   s p e c i f i c a t i o n   // s ím bo lo i n i c i a l  2   t r a v e r s a l ∗   path   // s u b s t it u i ç ã o de s p e c i f i c a t i o n  

3   path   // t r a v e r s a l é o p ci o na l  

4   s t e p | [ s t ep + ]   // s u b s t i t u i ç ã o de p at h  

5   s te p   // e s c o l h a do p r i me i r o ramo

6   ID | ID . p at h | ID ( )   // s u b s t i t u i ç ão de s t e p

7   ID   // e s c o l h a do p r i me i r o ramo

8   s e n d e r   // ID g e ra s e n de r  

Figura 16 – Geração da especificação da Figura 15 a partir da gramática de  Litoral.

1   r e c i p i e n t s

Figura 17 – Especificação  Litoral que navega através de coleções de objetos.

3.3.1 Navegando Através de um Único Atributo

O método   pr intMessage  da Figura 14 recebe uma mensagem como parâmetro e,

na linha 6, navega para seu remetente através do atributo   s e n d e r . A Figura 15 exibe

a especificação  Litoral  que declara esta navegação. Ela não faz nenhuma referênciaà mensagem, pois o objeto que dá início a navegações fica implícito nas especificações

Litoral. Por um lado, esta característica dificulta a compreensão de especificações

Litoral quando lidas independentemente do código onde elas serão embutidas. Por outro

lado, entretanto, ela torna as especificações Litoral mais concisas.

A Figura 16 mostra como gerar esta especificação a partir da gramática de  Litoral.

Para  Litoral é irrelevante se atributos referenciam objetos ou coleções de objetos.

A sintaxe que especifica navegações através de atributos é a mesma em ambos os casos.

A especificação  Litoral  da Figura  17,  por exemplo, declara uma navegação atravésdo atributo   r e c i p i e n t s , que referencia uma coleção de objetos. Ela possui a mesma

estrutura sintática que a especificação da Figura 15, a qual declara uma navegação através

do atributo   sender , que referencia um único objeto.

3.3.2 Navegando Através de mais de um Atributo

Nas linha 8 e 12, o método   pr intMessage   da Figura 14 também navega para

destinatários e anexos de mensagens através dos atributos  r e c i p i e n t s

  e  attachments

,respectivamente. A Figura 18 exibe a especificação  Litoral que declara navegações de

mensagens para seus remetentes, destinatários e anexos. Os caracteres   [  (abre colchetes) e

Page 38: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 38/162

Page 39: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 39/162

Capítulo 3.   Litoral   38

1   [

2   s e n d e r

3   r e c i p i e n t s

4   at tac hme nts . mediaType

5   ]

Figura 21 – Especificação  Litoral que navega indiretamente.

1   [

2   sen der . pi ct ur e . mediaType

3   r e c i p i e n t s

4   at tac hme nts . mediaType

5   ]

Figura 22 – Especificação  Litoral que encadeia navegações indiretas.

bastante para especificar navegações indiretas, ou seja, navegações de um objeto inicial

para um objeto intermediário e, deste último, para um objeto final, e assim por diante. Por

exemplo, na linha 15 da Figura 14, o método   pr intMessage  navega de um anexo de uma

mensagem para o seu tipo. Neste exemplo, a mensagem, o anexo e o tipo atuam como o

objeto inicial, intermediário e final, respectivamente. A linha 4 da especificaçãoLitoral

exibida na Figura 21 incorpora esta navegação indireta através do operador   .   (ponto).

Em navegações indiretas, é comum que um objeto intermediário funcione como oobjeto inicial de uma nova navegação indireta. Navegações deste tipo são especificadas

em  Litoral encadeando aplicações do operador   .   (ponto). O método   pr intMessage

da Figura 14, por exemplo, navega de uma mensagem para seu remetente através do

atributo   sender , deste remetente para sua fotografia através do atributo   p i c t u r e  e desta

fotografia para o tipo do arquivo que a armazena através do atributo   mediaType. A linha

2 da especificação  Litoral exibida na Figura 22 incorpora esta navegação encadeando o

operador   .   (ponto).

Em navegações indiretas, é possível que o atributo que leva ao objeto intermediário

não referencie nenhum objeto ou referencie uma coleção vazia. Isto aconteceria, por exemplo,

se as navegações que a especificação da Figura  22  declara fossem realizadas a partir de

uma mensagem sem remetente ou sem anexos. No primeiro caso, não seria possível navegar

para a foto do remetente. No segundo caso, não seria possível navegar para o tipo dos

arquivos anexados à mensagem. Na maioria das linguagens de programação, navegações

indiretas através de atributos que não referenciam nenhum objeto provocam um erro em

tempo de execução. Estes erros não acontecem em Litoral pois as navegações indiretas

declaradas por uma especificação Litoral só serão realizadas quando possível, ou seja,quando existir o objeto intermediário e, caso ele seja uma coleção de objetos, apenas se

não for uma coleção vazia.

Page 40: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 40/162

Capítulo 3.   Litoral   39

1   [

2   sen der . pi ct ur e . mediaType

3   re c i pi en ts . p ic tu re . mediaType

4   at tac hme nts . mediaType

5   ]

Figura 23 – Especificação  Litoral que replica uma navegação.

1   v i s i tU s e r = p i c t u r e . m ed iaTyp e

2   [

3   s e n d e r . v i s i t U s e r ( )

4   r e c i p i e n t s . v i s i t U s e r ( )

5   at tac hme nts . mediaType

6   ]

Figura 24 – Especificação  Litoral que define uma travessia.

3.3.4 Travessias

O método   pr intMessage  da Figura 14 navega não só de uma mensagem até o

tipo da fotografia do seu remetente, mas também até o tipo da fotografia de cada um dos

destinatários desta mensagem. A linha 3 da especificação  Litoral exibida na Figura 23

incorpora esta última navegação.

Apesar de correta, a especificação da Figura 23 possui uma replicação indesejável,

pois mudanças no método   p r i n tU s e r  da Figura 14 precisarão ser refletidas nela duas

vezes.  Litoral permite que replicações deste tipo sejam eliminadas com travessias, que

nada mais são do que caminhos nomeados. Uma vez definida, pode-se usar o nome de uma

travessia para percorrer o seu caminho, iniciando a partir de diferentes objetos, quantas

vezes for necessário. A linha 1 da Figura 24, por exemplo, define uma travessia chamada

v i s i t U s e r  cujo caminho é   pi ct ur e . mediaType. As linhas 4 e 5 iniciam esta travessia a

partir do remetente e dos destinatários de uma mensagem, respectivamente.

A Figura 25 mostra como gerar esta especificação a partir da gramática de  Litoral.

3.3.5 Travessias Recursivas

Travessias podem iniciar outras travessias e, em particular, a si mesmas. Isto nos

permite escrever a versão final da especificação  Litoral  que declara os objetos pelos

quais o método   pr intMessage  da Figura 14 navega. Esta última versão, exibida na Figura

26, define nas linhas 1 e 3 as travessias   v i s i t U s e r   e   v i s i t M e s s a g e , respectivamente. A

travessia   v i s i t M e s s a g e , além de iniciar a travessia   v i s i t U s e r  nas linhas 4 e 5, inicia asi mesma na linha 8.

A linha 8 da especificação da Figura 26 sugere uma recursão infinita. Entretanto,

Page 41: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 41/162

Capítulo 3.   Litoral   40

1   s p e c i f i c a t i o n   // s ím bo lo i n i c i a l  

2   t r a v e r s a l ∗   path   // s u b s t i t u i ç ã o de program  

3   t r a v e r s a l p at h   // s u b s t it u i ç ã o de t r a v e rs a l  ∗

4   ID=path path   // s u b s t it u i ç ã o de t r a v e rs a l  

5

6   ID=path   // e s p aç o s em b ra nc o s ão i g n o r ad o s  

7   path

8

9   v i s i tU s e r = p a th   // ID g er a v i s i t U s e r  10   path

11

12   v i s i tU se r=pic tur e . mediaType   / / p a th gera p ic tu r e . med ia Type  

13   [   // p at h g er a [  

14   send er . ste p   // sen d er . s t e p

15   r e c i p i e n t s . s t e p   // r e c i p i e n t s . s t e p

16   ]   // ] 

17

18   v i s i tU se r=pic tur e . mediaType

19

  [20   s e n d er . ( ID | ID . p at h | ID ( ) )   // s u b s t it u i ç ã o de s t ep

21   r e c i p i e n t s . ( ID | ID . pa th | ID ( ) )   // s u b s t it u i ç ã o de s t ep

22   ]

23

24   v i s i tU se r=pic tur e . mediaType

25   [

26   sender . ID( )   // e s c o l ha do t e r c e i r o ramo

27   r e c i p i e n t s . ID ( )   // e s c o l ha do t e r c e i r o ramo

28   ]

29

30   v i s i tU se r=pic tur e . mediaType

31   [

32   s e n d e r . v i s i t U s e r ( )   // ID g er a v i s i t U s e r  

33   r e c i p i e n t s . v i s i t U s e r ( )   // ID g er a v i s i t U s e r  

34   ]

Figura 25 – Geração da especificação da Figura 24 a partir da gramática de  Litoral.

Page 42: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 42/162

Page 43: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 43/162

Capítulo 3.   Litoral   42

1   Inductive   CLASS : = C l a s s : s t r i n g   −> l i s t ( s t r i n g   ∗   s t r i n g )   −> CLASS.

2

3   Inductive   OBJ := Obj : s t r i n g   −> l i s t ( s t r i n g   ∗   l i s t s t r i n g )   −> OBJ.

Figura 27 – Representação de classes e objetos no interpretador definidor.

apenas o primeiro. Outra diferença importante é que apenas funções totais1 são definíveis

em Gallina. Standard ML, por outro lado, suporta tanto funções totais quanto parciais.

3.4.1 Representação de Classes e Objetos

Litoral foi concebida para ser embarcada em linguagens orientadas a objetos que

suportam reflexão. Infelizmente, classes, objetos e reflexão não estão presentes em Gallina.Portanto, o primeiro passo para implementar o interpretador consiste em representar estes

conceitos a partir daqueles suportados por Gallina.

Do ponto de vista de  Litoral, objetos são apenas entidades que associam nomes

a valores. Conceitos como herança e polimorfismo, por exemplo, não são relevantes.

Adicionalmente, não importa para  Litoral se um atributo referencia um único objeto ou

uma coleção de objetos. Por fim, a distinção entre objetos e valores de tipos primitivos

presentes em algumas linguagens orientadas a objetos como Java também não é relevante.

Estas observações, acrescidas da necessidade de reflexão, motivam a representação declasses e objetos com os tipos exibidos na Figura  27.

Um valor do tipo   CLASS representa uma classe e é construído a partir do nome

( s t r i n g )  e dos atributos   ( l i s t )  desta classe. Cada atributo é representado por um par

( s t r i n g   ∗   s t r i n g )  onde o primeiro e o segundo elemento são, respectivamente, o nome

do atributo   ( s t r i n g )   e o nome de sua classe   ( s t r i n g ) .

Por sua vez, um valor do tipo   OBJ representa um objeto e é construído a partir

do identificador   ( s t r i n g )  e dos atributos   ( l i s t )  deste objeto. Cada atributo é repre-

sentado por um par   ( s t r i n g   ∗   l i s t s t r i n g )  onde o primeiro e o segundo elemento são,respectivamente, o nome   ( s t r i n g )  e o valor do atributo   ( l i s t s t r i ng ) .

O valor de um atributo é representado por uma lista de identificadores de objetos.

Esta representação simplifica a implementação do interpretador, pois permite que ele lide

uniformemente com atributos que referenciam um único objeto ou coleções de objetos.

Valores do tipo   CLASS referenciam-se indiretamente através de seus nomes. De

maneira similar, valores do tipo   OBJ referenciam-se indiretamente através de seus identifi-

cadores. Por um lado, estas indireções dificultam a implementação do interpretador. Por

outro lado, elas tornam possível a definição e a instanciação de classes e objetos que se1 Uma função  f  é chamada de total quando para todo elemento  x  de seu domínio existe um elemento  y

de seu contradomínio tal que  f (x) = y, caso contrário,  f  é chamada de parcial.

Page 44: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 44/162

Capítulo 3.   Litoral   43

1   Definition   c l a s s e s : = [

2   Class "MediaType" [ ] ;

3   Class " Fi le " [ ( " mediaType " , "MediaType " ) ]

4   Cl a s s " U se r " [ ( " p i c t u r e " , " F i l e " ) ] ;

5   C l a s s " M e ss ag e " [ ( " s e n de r " , " U s er " ) ; ( " r e c i p i e n t s " , " U s er " ) ;6   (" re p l i es " , " Message " ) ] ;

7   ] .

Figura 28 – Criação de classes no interpretador definidor.

1   Definition   I D : = s t r i n g .

2

3   Inductive   STEP :=

4   L a st S t ep : ID  −> STEP | S tep : ID  −> PATH  −> STEP | I n i t : ID  −> STEP

5

6   with   PATH := Path : nat   −> l i s t STEP  −> PATH.

7

8   Inductive   TRAV := Trav : ID  −> PATH −> TRAV.

9

10   Inductive   SPEC := Spec : l i s t TRAV  −> PATH −> SPEC.

Figura 29 – Representação de especificações  Litoral no interpretador definidor.

auto-referenciam direta ou indiretamente. O código Gallina da Figura 28,  por exemplo,cria as classes   MediaType,   F i l e ,   User   e   Message. Esta última se auto-referencia no

atributo   r e p l i e s .

3.4.2 Representação de Especificações  Litoral

Especificações   Litoral   são representadas através de tipos que mimetizam a

gramática da linguagem, tal como exibido na Figura 29. O trecho de código Gallina exibido

na Figura 30, por exemplo, mostra como instanciar a especificação  Litoral da Figura 26

a partir destes tipos.

Um valor do tipo   PATH é criado, tal como especificado pela gramática de  Litoral,

a partir de uma lista de passos   ( l i s t STEP)  e também de um número natural   ( n a t )

cuja função será descrita na seção 3.4.3. Por hora, é suficiente saber que valores do tipo

PATH podem ser criados a partir do número   0, tal como exemplificado na Figura 30.

3.4.3 Análise Semântica

Uma especificação Litoral

 é semanticamente válida quando ela:

1. não define travessias com nomes repetidos;

Page 45: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 45/162

Capítulo 3.   Litoral   44

1   Definition   s p ec := S pec [

2   Trav " v i s i t U s e r " ( P at h 0 [

3   S tep " p i c t u r e " (Path 0 [ L a s tS te p " m ed ia Ty pe " ] )

4   ] ) ;

5   Trav " v i s i t M e s s a g e " ( P at h 0 [6   S tep " s e n d e r " (Path 0 [ In i t " v i s i t U s e r " ] ) ;

7   S te p " r e c i p i e n t s " ( P at h 0 [ I n i t " v i s i t U s e r " ] ) ;

8   Step " attachments " (Path 0 [ LastSt ep "mediaType " ] ) ;

9   S te p " r e p l i e s " ( P ath 0 [ I n i t " v i s i t M es s a g e " ] )

10   ] )

11   ] ( P ath 0 [ I n i t " v i s i t M e s s a g e " ] ) .

Figura 30 – Criação de uma especificação  Litoral no interpretador definidor.

2. não inicia travessias inexistentes;

3. não referencia atributos inexistentes.

A função   analyzeSpec da Figura 31d verifica se especificações  Litoral satisfazem

estas condições dividindo o trabalho entre as funções aninhadas   indexSpec  da Figura

31a,   analyzeTravs  da Figura 31d,   analyzePath  da Figura 31c e   a n a l y z e Cl a s s Pa th s

da Figura 31d.

A função   indexSpec  recebe uma especificação  Litoral como argumento e retornauma tripla cujo primeiro elemento é uma nova especificação   spec2   quase idêntica à

primeira. A única diferença entre elas é que os índices (os números naturais) dos caminhos

contidos em   s p e c 2  são únicos. Portanto, é possível decidir se dois caminhos contidos em

s p e c 2  são iguais comparando seus índices. O terceiro elemento da tripla retornada por

indexSpec é uma lista formada pelos caminhos contidos em   spec2 . O segundo elemento,

por sua vez, é o tamanho desta lista.

A função   analyzeTravs  verifica a primeira condição. Por ser trivial, esta subseção

não discute sua implementação.

Page 46: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 46/162

Page 47: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 47/162

Capítulo 3.   Litoral   46

1   Definition   s t r E q x y : =   i f    s t r i n g _ d e c x y   then   t r u e   e l s e   f a l s e .

2

3   Definition   g e tPath tr a v s nm :=

4   l e t

5   f t ra v :=   l e t   ’Trav nm’ _ := trav   in   str Eq nm’ nm6   in

7   match   f i n d f t r a v s   with

8   | None => None

9   | Some (Trav _ path) => Some path

10   end .

11

12   Definition   emptyPath := Path 0 [ ] .

13

14   Definition   g e t C l a s s c l a s s e s nm :=

15   f i n d ( f un c l a s s =>   l e t   ’ C l a s s nm ’ _ := c l a s s   in   s t r Eq nm ’ nm) c l a s s e s .16

17   Definition   g e t C l a s s A t t r c l a s s nm :=

18   l e t

19   f ( a tt r : s t r i n g   ∗   s t r i n g ) :=   l e t   (nm ’ , _) : = a tt r   in   str Eq nm’ nm

20   in

21   l e t   ’ C la ss _ a t t r s := c l a s s   in   f i n d f a t t r s .

22

23   Definition   g e tA t t r Cl a s s c l a s s e s c l a s s nm :=

24   match   g e t C la s s At t r c l a s s nm   with

25   | None => None26   | Some (_, nm ’ ) => g e tCl a s s c l a s s e s nm ’

27   end .

28

29   Definition   a na ly ze St ep c l a s s e s t r av s c l a s s s t ep :=

30   l e t   g e tA ttr Cl a s s H e l p e r n m p a th : =

31   match   g et A tt r Cl a ss c l a s s e s c l a s s nm   with

32   | None => None

33   | Some c l a s s => Some ( c l a s s , p ath )

34   end

35   in

36   match   s te p   with

37   | LastStep nm => getA ttrC lass Helpe r nm emptyPath

38   | Step nm path => getAt trCl assHe lper nm path

39   | In i t nm =>

40   match   g etPa th tr a v s nm   with

41   | None => None

42   | Some path => Some ( c l as s , path)

43   end

44   end .

(b)

Figura 31 – Analisador semântico - continuação

Page 48: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 48/162

Page 49: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 49/162

Capítulo 3.   Litoral   48

1   Fixpoint   an a ly z eC l as s Pa t hs c l a s s e s p at hs t r a v s s c l a s s Pa t h s n :=

2   match   n   with

3   | 0 => (s , Some c l a s s Pa t h s )

4   | S n ’ =>

5   match   a n al y ze C la s sP a th s c l a s s e s p at hs t r a v s s c l a s sP a t h s n ’   with

6   | ( s ’ , None) => (s ’ , None)

7   | ( s ’ , Some [ ] ) => (s ’ , Some [ ] )

8   | ( s ’ , Some ( c l a s s P a t h : : c l a s s Pa t h s ’ ) ) =>

9   i f    c o n t a in s C l a ss P a t h s ’ c l a s s P a t h   then   ( s ’ , Some c l a s s Pa th s ’ )

10   e l s e

11   i f 

12   c o n t a in s C l a s sP a t h ( l i s t _ p r o d c l a s s e s p at h s ) c l a s s P a t h

13   then

14   l e t   s ’ ’ := c l a ss P a t h : : s ’   in

15   l e t   ( c l a s s , p at h ) := c l a s s P a t h   in

16   match   a na ly ze Pa th c l a s s e s t r a v s c l a s s p at h   with

17   | None => ( s ’ ’ , None)

18   | Some c lassP aths ’ ’ =>

19   (s ’ ’ , Some ( c lassP aths ’ ++ c lassP aths ’ ’ ) )

20   end

21   e l s e

22   ( s ’ , Some c l a s s Pa th s ’ )

23   end

24   end .

25

26   Definition   analyzeTravs ( tra vs : l i s t TRAV) := true .

27

28   Definition   a na ly ze Sp ec c l a s s e s c l a s s s pe c n :=

29   l e t   ’ ( s p ec 2 , i d x , p a ths ) := i n d ex S p e c s p e c   in

30   l e t   ’ S pe c t r a v s p at h : = s p e c2   in

31   i f    a n al y z e Tr av s t r a v s   then

32   a n al y ze C la s sP a th s c l a s s e s p at hs t r a v s [ ] [ ( c l a s s , p a th ) ] n

33   e l s e   ( [ ] , None ) .

(d)

Figura 31 – Analisador semântico - continuação.

Page 50: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 50/162

Page 51: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 51/162

Capítulo 3.   Litoral   50

1   Theorem   analyzeSpecLim :

2   f o r a l l c l a ss e s c l a s s spec ,

3   e x i s t s N,

4   f o r a l l n ,

5   l e t   ( _, t ) := a n al y ze Sp e c c l a s s e s c l a s s s p ec (N + n )   in

6   t = None \/ t = Some [ ] .

Figura 32 – Teorema que assegura que o analisador semântico do interpretador definidorsempre é capaz de validar especificações  Litoral em um número finito derecursões.

um um número finito de recursões   N suficiente para que a função   analyzeSpec   conclua

se a especificação   spec  é ou não semânticamente válida. O teorema também afirma que a

conclusão da função   a n a l yz e S p e c  é definitiva, pois permitir que a função   a n a l yz e S p e c

invoque a si mesma recursivamente um número de vezes maior do que   N (ou seja, um

número da forma   N + n, onde   n é um número natural qualquer), não modifica a conclusão

da função   analyzeSpec . A Seção C.8  contém a demonstração deste teorema verificada

por Coq. Ela se baseia no fato de que sequências monótonas e limitadas são convergentes

(THOMSON; BRUCKNER; BRUCKNER, 2008).

3.4.4 Interpretação

A função   i n t e r p r e t S p e c  exibida na Figura 33c recebe os argumentos   S,   f i l t e r ,

s ,   spec ,   a l l O b j s ,   o b j s  e   n e retorna uma tripla na qual o primeiro elemento é uma lista

de objetos. Esta seção discutirá   S,   f i l t e r   e   s  em breve. Os argumentos   spec ,   o b j s ,

a l l O b j s   e   n, são, respectivamente, uma especificaçãoLitoral, uma lista formada pelos

objetos a partir dos quais   s p e c  navega, uma lista contendo todos os objetos pelos quais

s p e c  navega e o número de vezes que a função   i n te r p r e tO b j s Pa th s  invocará a si mesma.

Sejam   SVal,   f i l t e r V a l  e   sVal valores apropriados para os argumentos   S,   f i l t e r

e   s , respectivamente. Então   i n t e r p r e t S p e c SVal f i l t e r V a l s Va l é uma função que

associa especificações  Litoral a funções que recebem e retornam listas de objetos, ou

seja,

interpretSpec SVal filterVal sVal define uma semântica para  Litoral

Mais especificamente,   i n t er p r et S p ec SVal f i l t e r V a l s Va l é uma função que associa

especificações Litoral a funções que:

•  recebem os argumentos   a l l O b j s ,   o b j s   e   n;

Page 52: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 52/162

Capítulo 3.   Litoral   51

1   Definition   get Obj a l l i d : =

2   f i n d ( f u n o b j =>   l e t   ’ Obj i d ’ _ := o b j   in   s tr Eq i d ’ i d ) a l l .

3

4   Fixpoint  ge tO bj s a l l i d s : =

5   match   i d s   with

6   | [ ] => Some [ ]

7   | i d : : i d s ’ =>

8   match   g et Ob js a l l i d s ’   with

9   | None => None

10   | Some objs ’ =>

11   match   get Ob j a l l i d   with

12   | None => None

13   | Some obj => Some ( obj : : objs ’ )

14   end

15   end

16   end .

17

18   Definition   g e tO bj A ttr a t tr s nm :=

19   l e t

20   f ( a tt r : s t r i n g   ∗   l i s t s t r i n g ) : =   l e t   (nm ’ , _) := a tt r   in   strEq nm’ nm

21   in

22   f i nd f a t t r s .

23

24   Definition   g e tV al a l l o bj nm :=

25   l e t   ’ O b j _ a t t r s : = o b j   in

26   match   ge tO bj A ttr a t tr s nm   with

27   | None => None

28   | Some (_ , v a l ) => g e tO b js a l l v a l

29   end .

30

31   Fixpoint   g e tV a ls a l l o b j s nm :=

32   match   o b j s   with

33   | [ ] => Some [ ]

34   | o b j : : o b js ’ =>

35   match   g e tV a ls a l l o bj s ’ nm   with

36   | None => None

37   | Some vals ’ =>

38   match   ge tV al a l l o b j nm   with

39   | None => None

40   | Some val => Some ( val ++ vals ’ )

41   end

42   end

43   end .

(a)

Figura 33 – Interpretador definidor.

Page 53: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 53/162

Capítulo 3.   Litoral   52

1   Definition   i n t er p re t St e p t ra vs a l l o bj s s te p :=2   l e t

3   g e tV a l s H e l p e r nm p ath : =

4   match   ge t Va l s a l l o b j s nm   with

5   | None => None

6   | Some vals => Some ( vals , path)

7   end

8   in

9   match   s te p   with

10   | Last Step nm => get Vals Help er nm emptyPath

11   | Step nm path => getVals Helper nm path12   | In i t nm =>

13   match   g etPa th tr a v s nm   with

14   | None => None

15   | Some path => Some ( objs , path)

16   end

17   end .

18

19   Fixpoint   i n t er p re t St e p s t ra vs a l l o bj s s t ep s : =

20   match   s t e p s   with

21   | [ ] => Some [ ]22   | s t e p : : s t ep s ’ =>

23   match   i n t er p r e t St e p s t r av s a l l o b js s te ps ’   with

24   | None => None

25   | Some objsPath ’ =>

26   match   i nt e rp r et S te p t ra vs a l l o bj s s te p   with

27   | None => None

28   | Some objsPath => Some ( objsPath : : objsPath ’ )

29   end

30   end

31   end .32

33   Definition   i n t er p re t Pa t h t r av s a l l o b js pat h :=

34   l e t   ’ P ath _ s t e p s := p at h   in   i n t e r p re t S t e p s t r av s a l l o b js s t e ps .

35

36   Definition   F i l t e r S : = S   −> l i s t OBJ  −> PATH  −> S   ∗   l i s t OBJ .

(b)

Figura 33 – Interpretador definidor - continuação.

Page 54: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 54/162

Page 55: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 55/162

Page 56: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 56/162

Capítulo 3.   Litoral   55

1   Definition   f i l t e r 1 ( s : l i s t OBJ) ( obj s : l i s t OBJ) ( path : PATH) :=

2   ( s , o b j s ) .

3

4   Definition   i n t e r p r e t S p e c 1 : =

5   int erp ret Spe c (S := l i s t OBJ) f i l t e r 1 [ ] .

Figura 35 – Semântica 1.

1   v i s i t M e s s a g e= r e p l i e s . v i s i t M e s s a g e ( )

2   v i s i t Me s s a g e ( )

Figura 36 – Especificação  Litoral que entra em recursão infinita na semântica 1.

1   Definition   p i c t u r e := Obj " p1 " [ ] .

2

3   Definition   u s e r : = Obj " u 1 " [ ( " p i c t u r e " , [ " p 1 " ] ) ] .

4

5   Definition   message := Obj "m1" [ ( " sender " , [ " u1 " ] ) ;

6   (" re c i pi en ts " , [ " u1 " ] ) ;

7   (" re pl ie s " , [ " m1 " ] ) ] .

Figura 37 – Mensagem que se auto-referencia.

do passado para tomar esta decisão, ela retorna o mesmo estado recebido como argumento,ou seja, a função   f i l t e r 1  permanece sempre em seu estado inicial.

A função   i n t e r p r e t S p e c 1  é construída a partir de   i n t e r p r e t S p e c  adotando como

filtro a função   f i l t e r 1  e como estado inicial uma lista vazia. A função   i n t e r p r e t S p e c 1 ,

portanto, define uma semântica para   Litoral. Esta semântica será denominada de

semântica 1.

A semântica 1 possui uma propriedade indesejável: ela associa especificações  Li-

toral recursivas a funções que entram em recursão infinita ao navegar por objetos que se

auto-referenciam direta ou indiretamente. Isto acontece, por exemplo, com a especificaçãoLitoral   spec1  e o objeto   message  exibidos nas Figuras 36 e  37, respectivamente.

É fácil ver por que   spec1  entra em recursão infinita neste caso. A primeira coisa

que   spec1 faz é iniciar a travessia   v i s i t M e s s a g e  a partir de uma lista contendo   message:

[ message ] . vi si tM es sag e ()

A substituição de   v i s i t M e s s a g e  por seu caminho resulta em

[ message ] . r ep l i es . v is it Mes sage ()

Page 57: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 57/162

Page 58: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 58/162

Page 59: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 59/162

Page 60: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 60/162

Capítulo 3.   Litoral   59

1   Definition   objPathEq ( objPath objPath ’ : OBJ   ∗   PATH) :=

2   l e t   ( o b j , p ath ) : = o b j Path   in

3   l e t   ( obj ’ , path ’ ) := objPath ’   in

4   i f    o bj Eq o b j o b j ’   then   pathEq path path ’   e l s e   f a l s e .

5

6   Fixpoint   c o n ta in s O bj Pa th o b j Path s o b jPa th :=

7   match   objPaths   with

8   | [ ] => f a l s e

9   | objPath ’ : : objPaths ’ =>

10   i f    containsObjPath objPaths ’ objPath   then   t r u e

11   e l s e   objPathEq objPath ’ objPath

12   end .

13

14   Fixpoint   f i l t e r 3 ( paths : l i s t PATH) ( al lO bj s : l i s t OBJ)

15   ( s : l i s t (OBJ   ∗   PATH)) ( obj s : l i s t OBJ) ( path : PATH) :=16   match   o b j s   with

17   | [ ] => (s , [ ] )

18   | o b j : : o b js ’ =>

19   l e t   ( s ’ , o u tO b js ) : = f i l t e r 3 p a th s a l l O b j s s o b j s ’ p ath   in

20   l e t   o b j Pa th := ( o b j , p ath )   in

21   i f    c o n ta i n sO b j Pa th ( l i s t_ p r o d a l l O b j s p a ths ) o b jPa th   then

22   i f    containsObjPath s ’ objPath   then   ( s ’ , o u tO b js )

23   e l s e   ( o b j Pa th : : s ’ , o b j : : o ut Ob js )

24   e l s e

25   ( s ’ , o u tO b js )26   end .

27

28   Definition   i n t e r pr e t Sp e c3 s pe c a l l Ob j s o b js n :=

29   l e t   ’ ( s p ec ’ , _ , _) := i n d e xS p e c s p e c   in

30   i n te r p r e t S p e c (S := l i s t (OBJ   ∗   PATH)) f i l t e r 3 [ ] spec ’ a l l Obj s objs n .

Figura 42 – Semântica 3.

Portanto, na semântica 3   spec1  não entra em recursão infinita ao navegar a partir demessage .

Voltando ao primeiro exemplo da seção 3.4.4.3,   f i l t e r 3  permitirá que   spec2

navegue novamente de   message  para   u s e r  através do atributo   r e c i p i e n t s , pois   spec2

ainda não percorreu o caminho   p i c t u r e  a partir de   u s e r , resultando na lista

[ m es sa ge , u s e r , u s e r , p i c t u r e ]

ou seja, na semântica 3   spec2 parte de   message e realiza todas as navegações especificadas.Por fim, voltando ao segundo exemplo da seção  3.4.4.3, ao navegar a partir de

message ,   spec3  resulta na lista

Page 61: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 61/162

Capítulo 3.   Litoral   60

[ m es sa ge , u s e r , p i c tu r e , u s e r ]

mostrando que na semântica 3   spec2   e   spec3   partem de   message   e navegam pelos

mesmos objetos, ainda que em ordens diferentes.

3.4.4.5 Escolha de uma Semântica

Dentre as semânticas 1, 2 e 3, a última deve ser escolhida preferencialmente, pois ela

está livre dos problemas das anteriores. Entretanto, se há segurança de que as especificações

Litoral que serão executadas não definem travessias recursivas a partir de objetos que se

auto-referenciam, então a semântica 1 pode ser adotada. Especificamente nestes casos, a

semântica 1, assim como a semântica 3, também associa especificações Litoral a funções

que não entram em recursão infinita e que estão livres dos problemas da semântica 2.Adotar a semântica 1 é vantajoso, pois, por permanecer sempre em seu estado inicial, ela

é mais simples e demanda menos memória e processamento do que a semântica 3.

A discussão anterior pressupõe que a escolha de uma semântica é estática, ou seja,

toda e qualquer especificação  Litoral será executada sob a mesma semântica. Entretanto,

também é possível escolher uma semântica dinamicamente, em função da especificação

Litoral que será executada. Pode-se, por exemplo, procurar por travessias recursivas

na especificação  Litoral. Se elas forem encontradas, a semântica 3 é adotada. Caso

contrário, a escolha recai sobre a semântica 1.

Page 62: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 62/162

Page 63: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 63/162

Capítulo 4. Interpretador    62

dependências entre tarefas, sejam elas de dados ou temporais, e também declara quais

tarefas devem ser executadas em um novo contexto de execução2, cabendo ao ambiente de

tempo de execução gerenciar:

•   a sincronização, ou seja, executar as tarefas em uma ordem que respeite suas

dependências e, quando for o caso, em um novo contexto de execução (SCOTT,

2006);

•  a comunicação, isto é, disponibilizar para uma tarefa o resultado das tarefas das

quais ela depende (SCOTT, 2006).

Diferentemente de frameworks que foram criados para paralelizar processamento de

dados ((LEA, 2000), por exemplo),  Afluentes pode ser utilizado com primitivas de E/Sassíncronas, baseadas em callbacks ou multiplexadas, e também com primitivas síncronas.

4.1.1 Modelo de Programação

Esta subseção dá uma visão geral do modelo de programação de  Afluentes. Neste

modelo, tarefas são avaliações de funções. Por exemplo, sejam as funções  sub(x, y) = x− y

e  mul(x, y) = x × y. Então as avaliações  sub(0, 1) e  mul(2, 3) são tarefas.

Dependências entre tarefas são composições das avaliações subjacentes. Por exem-plo, dados  a,  b e  c, podemos calcular o valor de  b2 − 4ac com a composição de avaliações

sub(mul(b, b),mul(4,mul(a, c))). Ao se deparar com esta composição,  Afluentes identi-

fica, por exemplo, que a tarefa  mul(4,mul(a, c)) depende da tarefa  mul(a, c) e, portanto,

a primeira só pode ser executada depois da última.

Ao inspecionar composições de avaliações,  Afluentes também identifica tarefas

independentes.  Afluentes supõe que a execução de cada uma destas tarefas não tem

efeitos indesejáveis sobre as demais, portanto elas podem ser executadas concorrentemente.

No exemplo anterior, Afluentes

 identificaria que as tarefas  mul(b, b)  e  mul(a, c) sãoindependentes e, portanto, podem ser executadas concorrentemente.

A independência de tarefas é uma condição necessária, mas não suficiente, para que

elas sejam executadas concorrentemente. Isto acontecerá apenas se uma destas tarefas for

a avaliação de uma função assíncrona. Funções síncronas e assíncronas serão discutidas em

breve. Para os fins desta subseção, é suficiente saber que funções assíncronas são avaliadas

em um novo contexto de execução.

4.1.2 Funções SíncronasO código da Figura 43 calcula o valor de  b2− 4ac compondo invocações de métodos.

2 O termo thread foi evitado pois normalmente ele é interpretado como um processo leve.

Page 64: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 64/162

Page 65: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 65/162

Page 66: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 66/162

Page 67: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 67/162

Page 68: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 68/162

Capítulo 4. Interpretador    67

1   p ub l ic i n t e r f a c e   I Ca ll ba ck <Y> {

2   void   y(Y y ) ;

3   void   t ( Throwable t ) ;

4   }

Figura 48 – Interface ICallback.

1   p ub l ic i n t e r f a c e   IAsyncFn0<Y> {

2   void   y( IC all bac k<Y> cb ) ;

3   }

4

5   p ub l ic i n t e r f a c e   IAsyncFn1<X1, Y> {

6   void   y (X1 x1 , IC all bac k<Y> cb ) ;

7   }

8

9   p ub l ic i n t e r f a c e   IAsyncFn2<X1, X2, Y> {

10   void   y(X1 x1 , X2 x2 , ICal lback <Y> cb ) ;

11   }

Figura 49 – Interfaces IAsyncFn0, IAsyncFn1 e IAsyncFn2.

1   IAsyncFn2<Double , Double , Double> sub = (x , y , cb)   −> {

2   new   Thread ( ( )   −> c b . y (x   −   y ) ) . s t a r t ( ) ;

3   } ;

4

5   IAsyncFn2<Double , Double , Double> mul = (x , y , cb)   −> {

6   new   Thread ( ( )   −> c b . y (x   ∗   y ) ) . s t a r t ( ) ;

7   } ;

Figura 50 – Funções  sub e  mul definidas com as interfaces IAsyncFn2.

4.1.7 Representando Funções Assíncronas

As interfaces   IAsyncFn0, ...,   IAsyncFn16   exibidas na Figura   49   são versões

assíncronas das interfaces   ISyncFn0, ...,   ISyncFn16. Como funções assíncronas entregam

o resultado de suas avaliações através de callbacks, os métodos   y das interfaces   IAsyncFn0,

...,   IAsyncFn16 têm tipo de retorno   vo id  e recebem como último parâmetro um callback.

A Figura 50 exibe as funções assíncronas   mul  e   su b, mas desta vez definidas com

as interfaces   IAsyncFn2.

4.1.8 Avaliações

Avaliações são objetos cujas classes implementam a interface   IEval  exibida naFigura 51. Ao ser invocado pela primeira vez, o método   y executa o processo de avaliação

descrito na seção 4.1.4. O resultado deste processo é armazenado na avaliação de forma

Page 69: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 69/162

Capítulo 4. Interpretador    68

1   p ub l ic i n t e r f a c e   IEval<Y> {

2   Y y ( ) ;

3   }

Figura 51 – Interface IEval.

1   p ub l ic i n t e r f a c e   IFnEval0<Y> {

2   IEval<?   extends   Y> y ( ) ;

3   }

4

5   p ub l ic i n t e r f a c e   IF nEva l1<X1 , Y> {

6   IEval<?   extends   Y> y( X1 x1 ) ;

7   IEval<?   extends   Y> y ( IEval <?   extends   X1> x1 );

8   }

Figura 52 – Interfaces IEval0 e IEval1.

que invocações subsequentes do método   y não precisam executar o processo de avaliação

novamente.

4.1.9 Avaliadores

Avaliadores são objetos cujas classes implementam uma das interfaces   IFnEval0,

...,   IFnEval16. A Figura 52 exibe as duas primeiras.

As classes   ISyncEval0, ...,   ISyncEval16   e   IAsyncEval0, ...,   IAsyncEval16

são adaptadores que transformam funções síncronas e assíncronas, respectivamente, em

avaliadores. Elas podem ser vistas em ação nos códigos das figuras 53 e 54 que calculam

b2− 4ac, mas desta vez compondo invocações de avaliadores de funções síncronas e

assíncronas. A comparação destes códigos concorda com as afirmações da seção  4.1.3:

•   a transformação de funções assíncronas em avaliadores (linhas 1 a 3 da Figura 54)

permite que suas invocações sejam compostas (linha 8 da Figura  54) com a mesma

facilidade do caso síncrono (linha 6 da Figura 53);

•  a transformação de funções síncronas em avaliadores (linhas 1 e 3 da Figura 53  e

linha 5 da Figura 54) permite que os dois tipos de funções sejam misturados em

uma mesma composição de avaliações (linha 6 da Figura 53).

Apesar dos métodos   d e l t a  das figuras 53 e  54 serem idênticos, suas execuções são

bastante diferentes. O primeiro é executado sequencialmente, pois envolve apenas funçõessíncronas. O último é executado concorrentemente, pois envolve tanto funções síncronas

quanto assíncronas.

Page 70: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 70/162

Page 71: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 71/162

Capítulo 4. Interpretador    70

percorre esta árvore em busca de avaliações que podem ser executadas. As avaliações

m u l ( b , b )  e   mul (a , c )  satisfazem este critério. Elas são executadas concorrentemente,

pois estão relacionadas a funções assíncronas.

Suponha que   m u l ( b , b )  seja concluída primeiro, levando a árvore de avaliações àconfiguração da Figura 55b.  Afluentes percorre esta configuração em busca, novamente,

de avaliações que podem ser executadas, mas desta vez não encontrará nenhuma.

A Figura 55c exibe a configuração da árvore de avaliações quando   mul (a , c )

é concluída. Neste momento,   Afluentes   executa uma nova busca e descobre que

mul(4 .0 , mul(a , c ))  já pode ser executada. Quando esta avaliação é concluída, a árvore

de avaliações evolui para a configuração da Figura 55d. Uma nova busca revela que a raíz

da árvore de avaliações pode, enfim, ser executada. Quando esta avaliação chega ao fim, a

árvore de avaliações evolui para a configuração final exibida na Figura 55e.

4.1.10 Funções sobre Listas

Sejam X1 e Y tipos quaisquer. Funções sobre listas são objetos que implementam

a interface   ISyncFn1<List<X1>, Y>, ou seja, são funções síncronas cujo domínio e con-

tradomínio são, respectivamente, listas de   X1 e   Y. O código da Figura 56, por exemplo,

define as funções sobre listas   sum e   p r o d u c t s . A primeira associa uma lista de produtos

ao somatório dos seus preços. A segunda associa uma lista de códigos de produtos a uma

lista dos respectivos produtos.

4.1.11 Avaliadores de Funções sobre Listas

Existem casos em que é necessário aplicar uma função sobre listas

ISyncFn 1<Li st <X1>, Y> a uma lista de avaliações de   X1 (   List<IEval<X1>>). O Adapta-

dor   SyncEval1  não ajudará nestes casos, pois ele permite que a função sobre listas seja

aplicada a avaliações de listas de   X1 (   IEval<List<X1>>) mas não a listas de avaliações

de   X1. O adaptador   L i s t E v a l , por outro lado, permite a última aplicação.   L i s tEv a lrecebe uma lista de avaliações de   X1, espera que todas as avaliações sejam concluídas,

constrói uma nova lista contendo o resultado das avaliações (   List<X1>) e, finalmente,

aplica a função à nova lista.

Voltando ao exemplo da Figura 56, o método   t o t a l  recebe uma lista de códigos de

produtos e calcula o somatório dos preços dos respectivos produtos compondo invocações

das funções   sum  e   products . Como   products  carrega os produtos para a memória

primária invocando a função   product , podemos aumentar o desempenho de   t o t a l

tornando   product  assíncrona, pois assim os produtos serão carregados concorrentemente.O código da Figura 57 incorpora esta mudança. Como a função   product  tornou-se

um avaliador, o contradomínio da função   products   passou de   List<Product> para

Page 72: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 72/162

Capítulo 4. Interpretador    71

1   ISyncFn1<Integ er , Product> product = id   −> {   / ∗   . . .   ∗/   } ;

2

3   ISyncFn1<List<Int ege r >, Lis t<Product>> pr oduc ts = id s   −> {

4   Lis t<Product> ps =   new   ArrayList <>();

5   f o r   ( I n t eg e r i d : i d s ) {6   Product p = product . y( id ) ;

7   ps . add( p ) ;

8   }

9   return   ps ;

10   } ;

11

12   ISyncFn1<Li st <Product >, Double> sum = ps   −> {

13   double   s = 0 ;

14   f o r   ( P rod uct p : p s ) {

15   s += p . pr ic e ;16   }

17   return   s ;

18   } ;

19

20   double   to ta l ( L i s t< In te g e r > i d s ) {

21   return   sum. y( products . y( id s )) ;

22   }

Figura 56 – Cálculo do somatório dos preços dos produtos de uma lista compondo invoca-ções de funções síncronas.

Lis t<IEval<? ext ends Product>>. Portanto, para que possamos aplicar a função   sum

aos resultados de   products , precisamos transformá-la em um avaliador com o adaptador

L i s tEv a l .

4.2 Projeto

A fase de implementação (MERNIK; HEERING; SLOANE, 2005) do desenvol-vimento de  Litoral determinou que seu interpretador deveria atender aos requisitos a

seguir.

Baixo acoplamento: se um sistema usa um mecanismo de carregamento de

objetos que se integra com o interpretador, então as únicas mudanças no código do sistema

necessárias ao uso do interpretador devem ser sua instanciação e execução.

Transparência: o uso do interpretador não deve modificar um sistema funcional-

mente. Seu único efeito deve ser a redução do tempo de carregamento de objetos.

Independência: o interpretador deve ser capaz de interagir com qualquer meca-

nismo de carregamento de objetos.

Page 73: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 73/162

Capítulo 4. Interpretador    72

1   IFnEval1<Inte ger , Product> product =   new   AsyncEval1<>((id , cb )   −> {

2   / ∗   . . .   ∗/ 

3   } ) ;

4

5   ISyncFn1<List<Int ege r >, Lis t<IEval<?   extends   Product>>> p rod uct s = id s   −> {6   List<IEval<?   extends   Prod uct>> ps =   new   ArrayList <>();

7   f o r   ( I n te g er i d : i d s ) {

8   IEval<?   extends   Product> p = product . y( id ) ;

9   ps . add( p ) ;

10   }

11   return   ps ;

12   } ;

13

14   IL ist Eva l<Product , Double> sum =   new   ListEval<>(ps   −> {   / ∗   . . .   ∗/   } ) ;

15

16   double   to ta l ( L i s t< In te g e r > i d s ) {

17   return   sum. y( products .y( ids )) . y ( ) ;

18   }

Figura 57 – Cálculo do somatório dos preços dos produtos de uma lista compondo avalia-dores de funções assíncronas e de funções sobre listas.

1   p ub l ic i n t e r f a c e   I Eva lHo ld er <Y> {

2   IEval<?   extends   Y> getE val ( ) ;

3   }

Figura 58 – Interface IEvalHolder.

Baixa exigência: o interpretador deve fazer poucas exigências aos mecanismos

de carregamento de objetos que desejam se integrar com ele.

O interpretador atende ao último requisito fazendo uma única exigência: os meca-

nismos devem carregar objetos sob demanda com proxies que implementam a interface

IEvalHolder  exibida na Figura 58.  O parâmetro de tipo   Y determina a classe do objetoque será carregado. O método   getEval  retorna a avaliação que carrega este objeto.

Mecanismos de carregamento de objetos atendem facilmente à exigência do interpre-

tador gerando proxies que, similarmente ao exibido na Figura 59, armazenam a avaliação

retornada pelo método   getEval  no atributo   e v a l  e sobrepõem todos os métodos de suas

classes-alvo. Os novos métodos obtêm os objetos-alvo dos proxies executando o processo

de avaliação (   e v a l . y ( ) ) e repassam para eles suas invocações.

A geração de proxies similares ao da Figura 59 também é responsável pelo cumpri-

mento do requisito de transparência. Quando um método do proxy é invocado, não fazdiferença se o interpretador já carregou o objeto-alvo do proxy executando o processo de

avaliação. Em caso positivo, a invocação será repassada para o objeto-alvo imediatamente.

Page 74: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 74/162

Page 75: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 75/162

Page 76: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 76/162

Page 77: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 77/162

Page 78: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 78/162

Page 79: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 79/162

Capítulo 4. Interpretador    78

(“”, Message)

(“visitMessage”, Message) (“visitMessage”, List<Message>)

Figura 65 – Tabela de símbolos da especificação  Litoral da Figura 63.

4.3.3 Interpretação

A idéia principal por trás da interpretação de especificações  Litoral com  Aflu-

entes consiste em construir composições de avaliações a partir de suas tabelas de símbolos.

As avaliações navegam por objetos, carregando-os para a memória primária se necessário.

As tabelas de símbolos contêm cópias das subárvores das ASTs das especificaçõesLitoral. As composições de avaliações são construídas à medida que os nós das subárvores

são percorridos. Os nós estão anotados com as classes dos objetos sobre os quais eles

atuam. Os objetos podem ser listas de outros objetos, ou seja, suas classes são subclasses

de   L i s t .

4.3.3.1 Nós que Atuam Sobre Objetos

Se  n é um nó que atua sobre um objeto, então  n  dá origem a uma composição de

avaliações das funções   head  e   e v a l u a t i o n s 1 .A função   e v a l u a t i o n s 1   recebe como argumentos os filhos de  n  e um objeto e

retorna uma lista de avaliações. A primeira avaliação da lista carrega o objeto. Se ele

implementa a interface   IEvalHolder , então a primeira avaliação é a retornada pelo método

getEval . Caso contrário, é a avaliação da função identidade aplicada ao objeto. As demais

avaliações da lista retornada por   e v a l u a t i o n s 1  correspondem a avaliações de funções

que, a partir do objeto recebido como argumento:

•  navegam através dos atributos cujos nomes estão contidos nos filhos de  n; ou

•  iniciam as travessias cujos nomes estão contidos nos netos de  n.

Page 80: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 80/162

Page 81: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 81/162

Capítulo 4. Interpretador    80

(a) (b)

(c)

(d)

(e)

Figura 66 – Interpretação de especificações  Litoral

Page 82: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 82/162

Page 83: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 83/162

Capítulo 4. Interpretador    82

(j)(k)

(l)

(m)

Figura 66 – Interpretação de especificações  Litoral - Continuação

Page 84: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 84/162

Page 85: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 85/162

Page 86: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 86/162

Capítulo 5. Avaliação   85

•   associações de cardinalidade muitos para muitos são mapeadas para tabelas cujas

chaves primárias são formadas por chaves estrangeiras que referenciam as tabelas

das classes associadas. Os atributos das associações, quando existirem, são mapeados

para colunas de suas tabelas;

•  subclasses são mapeadas para tabelas que contêm apenas seus atributos próprios

(aqueles que não foram herdados das superclasses). As tabelas das subclasses possuem

chaves estrangeiras que referenciam as tabelas das superclasses.

A Seção A.2 exibe as tabelas resultantes do mapeamento objeto-relacional. O banco

de dados é populado com um tipo de arquivo, uma marcação e cem usuários. Cada usuário

possui uma imagem e iniciou (ou seja, enviou a primeira mensagem de) mil conversações.

Cada uma das nove primeiras mensagens de uma conversação possui uma réplica, enquantoa última não possui réplicas. Portanto, cada conversação possui dez mensagens. Cada

mensagem possui um anexo e está associada a uma marcação. Resumindo, o banco de

dados é populado com 1 tipo de arquivo, 1 marcação, 100 usuários, 1.000.000 mensagens e

1.000.100 arquivos.

Emeio é composto pelas especificações  Litoral exibidas na Figura 67. As especi-

ficações C e G declaram navegações executadas durante a exibição da lista de mensagens

enviadas e recebidas por um usuário, respectivamente. A especificação L declara navegações

executadas durante a exibição de todas as mensagens que compõem uma conversação.As especificações A–B, D–F e H–K são versões simplificadas das especificações C, G e L,

respectivamente.

As especificações A–C e D–G são executadas, respectivamente, a partir das 50

últimas mensagens enviadas e recebidas por um usuário escolhido aleatoriamente. As

especificações H–L são executados a partir de mensagens escolhidas também aleatoriamente.

Todas as especificações são executadas 6.000 vezes. As 1.000 primeiras são ignoradas para

minimizar a interferência de custos de inicialização (por exemplo, carregamento de classes

e compilação just in time).

5.1.1 Implementação Baseada no Hibernate

A implementação de  Emeio baseada no Hibernate sofreu as seguintes otimizações:

1.   atributos do tipo II são carregados através de consultas que fazem uso do operador   i n

de SQL para carregar vários objetos, ou seja, a anotação   @BatchSize  foi adicionada

aos atributos anotados com   @ManyToOne ou   @ManyToMany;

2.  atributos do tipo II que referenciam objetos são carregados sob demanda, ou seja, o

atributo   f e t c h  das anotações   @ManyToOne recebu o valor   FetchType .LAZY;

Page 87: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 87/162

Capítulo 5. Avaliação   86

1   r e c i p i e n t s   // A

2

3   r e c i p i e n t s t ag s   // B 

4

5   r e c i p i e n t s t a gs f i l e s   // C 6

7   s e n d e r   // D 

8

9   s en de r r e c i p i e n t s   // E 

10

11   s en de r r e c i p i e n t s t ag s   // F 

12

13   s e nd e r r e c i p i e n t s t a gs f i l e s   // G 

14

15   v i s i t M e s s a g e = [ r e p l i e s . v i s i t M e s s a g e ( ) ]   // H 16   v i s i t Me s s a g e ( )

17

18   v i s i t M e s s a g e = [ s e n de r r e p l i e s . v i s i t M e s s a g e ( ) ]   // I 

19   v i s i t Me s s a g e ( )

20

21   v i s i t M es s a g e = [ s en d er r e c i p i e n t s r e p l i e s . v i s i t M es s a g e ( ) ]   // J 

22   v i s i t Me s s a g e ( )

23

24   v i s i t M es s a g e = [ s en d er r e c i p i e n t s t a g s r e p l i e s . v i s i t Me s s a ge ( ) ]   // K 

25   v i s i t Me s s a g e ( )26

27   v i s i t M es s a g e = [ s en d er r e c i p i e n t s t a g s f i l e s r e p l i e s . v i s i t Me s s a ge ( ) ]   // L

28   v i s i t Me s s a g e ( )

Figura 67 – Especificações  Litoral que compõem o benchmark  Emeio.

3. índices foram criados para as chaves estrangeiras de todas as tabelas;

4.  as tabelas   message_sender_view  e   message_rec ipient_view  exibidas na Figura68 foram adicionadas ao banco de dados. Elas armazenam, respectivamente, as 50

últimas mensagens enviadas e recebidas por cada usuário do sistema;

5.  índices foram criados para os pares de colunas das tabelas   message_sender_view  e

message_rec ipient_view com os comandos SQL exibidos na Figura  69.

As figuras 70a–70e exibem o tempo total de execução das especificaçõesLitoral

A–L com diferentes versões da implementação de  Emeio baseada no Hibernate. A Figura

70a exibe os tempos com as versões não otimizada e com a otimização 1, a Figura  70bexibe os tempos das versões com a otimização 1 e com as otimizações 1 e 2 combinadas,

e assim sucessivamente. Nas figuras 70a–70d o tempo total corresponde a 10 execuções

Page 88: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 88/162

Capítulo 5. Avaliação   87

Figura 68 – Tabelas adicionadas ao banco de dados para otimizar a implementação deEmeio baseada no Hibernate.

1   create index on   m e s s ag e _ r ec i p i en t_ v i ew ( r e c i p i e n t _ i d e n t i f i e r ,

2   m e s s a g e _ i d e n t i f i e r   desc ) ;

3

4   create index on   message_sender_view ( se nde r_i den ti f i er ,

5   m e s s a g e _ i d e n t i f i e r   desc ) ;

Figura 69 – Índices criados no banco de dados de  Emeio.

de cada especificação  Litoral, enquanto que na Figura  70e ele corresponde a 5.000

execuções. Foi necessário aumentar o número de execuções porque a redução no tempo

total proporcionada pela otimização 5 só se torna aparente com um número maior de

execuções.

Os dados exibidos nas figuras 70a–70e são sintetizados pelas seguintes observações:

•  aplicar a otimização 1 à versão não otimizada reduz o tempo total de execução das

especificações Litoral A–C e E–G em 75,1–78,8%;•  aplicar a otimização 2 à versão com a otimização 1 reduz o tempo total de execução

das especificações  Litoral A–G em 15,5–52,0%;

•  aplicar a otimização 3 à versão com as otimizações 1–2 reduz o tempo total de

execução de todas especificações  Litoral em 67,5–99,7%;

•  aplicar a otimização 4 à versão com as otimizações 1–3 reduz o tempo total de

execução das especificações  Litoral A–G em 68,1–89,6%;

•  aplicar a otimização 5 à versão com as otimizações 1–4 reduz o tempo total de

execução das especificações  Litoral A–G em 10,6–25,3%.

Page 89: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 89/162

Capítulo 5. Avaliação   88

(a)

(b)

(c)Figura 70 – Resultado das otimizações da implementação de  Emeio baseada no Hibernate.

Page 90: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 90/162

Page 91: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 91/162

Capítulo 5. Avaliação   90

recarregamento de objetos, enquanto a implementação baseada no interpretador não adota

esta otimização.

5.1.4 ResultadosAs figuras 71a–71c exibem o tempo total de execução das especificações A–L com

as implementações de  Emeio baseadas no Hibernate, EclipseLink JPA e no interpretador

de  Litoral.

Em muitos casos, o tempo total de execução com o interpretador no modo sequencial

é menor do que o obtido com o Hibernate e o EclipseLink JPA. É bastante provável que

isto ocorra porque o ORM com o qual o interpretador foi integrado possui apenas as

funcionalidades necessárias à implementação dos benchmarks, enquanto o Hibernate e

o EclipseLink JPA implementam uma série de outras funcionalidades que ajudam o

desenvolvedor, mas, eventualmente, reduzem o desempenho.

O tempo total de execução das especificações A, D e H com o interpretador no

modo concorrente foi 0,9–9,9% maior do que no sequencial. Este aumento ocorre porque a

otimização 1 da seção 5.1.1 elimina destas especificações as oportunidades para concorrência.

Em casos assim, o aumento no tempo de processamento oriundo do gerenciamento da

concorrência não é compensado por uma redução no tempo de E/S, pois as consultas

são executadas sequencialmente. Esta observação sugere que o interpretador deveria ser

capaz de identificar se uma especificação oferece oportunidades para concorrência. Em

caso negativo, o interpretador operaria no modo sequencial mesmo quando solicitado a

operar no modo concorrente.

Por outro lado, o tempo total de execução das demais especificações com o inter-

pretador no modo concorrente foi 33,3–69,1% menor do que no sequencial. De maneira

geral, quanto maiores forem as oportunidades para concorrência (especificações C, G e L),

maior é a redução no tempo total de execução.

Em algumas especificações, o tempo total de execução com o interpretador no modosequencial foi menor do que com as implementações baseadas no Hibernate (especificações

A–D e G–H) e EclipseLink JPA (especificações A–C e G). Em outras, foi maior. O pior

desempenho foi observado na especificação I, na qual o tempo total de execução mais

que dobrou. Entretanto, em todas as especificações que oferecem oportunidades para

pré-carregar objetos executando consultas concorrentemente, esta otimização fez com que

o tempo total de execução com o interpretador no modo concorrente fosse menor do que

com as implementações baseadas no Hibernate (8–62,3%) e EclipseLink JPA (8,1–56,4%).

Page 92: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 92/162

Capítulo 5. Avaliação   91

(a)

(b)

(c)

Figura 71 – Tempo total de execução das implementações de  Emeio baseadas no inter-pretador de  Litoral, Hibernate e EclipseLink JPA.

Page 93: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 93/162

Capítulo 5. Avaliação   92

5.2 OO7

OO7 é um benchmark livremente inspirado em sistemas de CAD (Computer Aided

Design), CAM (Computer Aided Manufacturing) e CASE (Computer Aided Software

Engineering). Ele foi projetado para avaliar o desempenho de navegações, atualizações e

consultas em OODBMs. Como o interpretador deLitoral influencia apenas o desempenho

de navegações, a implementação de OO7 desenvolvida nesta pesquisa, tal como (IBRAHIM;

COOK, 2006), se limita a esta parte do benchmark.

Os principais conceitos modelados por OO7 são:

•  partes compostas   (CompositePart)  representam primitivas de projeto básicas como,

por exemplo, um registrador em um sistema VLSI (Very Large Scale Integration)

CAD ou um procedimento em um sistema CASE. Uma parte composta possui uma

parte atômica   (AtomicPart)  raiz;

•  partes atômicas   (AtomicPart)  representam as unidades que compõem as partes

compostas. Em um sistema CASE, por exemplo, elas representariam variáveis,

comandos, expressões, etc. Uma parte atômica possui conexões com outras partes

atômicas;

•   conexões   ( Conne ction )  representam a conexão entre uma parte atômica de origem

e outra de destino;

•   montagens   (Assembly)   representam construções de projeto de alto nível como, por

exemplo, uma unidade lógica e aritmética em um sistema VLSI CAD. Montagens

podem ser formadas por partes compostas, caso em que são chamadas de montagens

base   (BaseAssembly) , ou por outras montagens, caso em que são chamadas de

montagens complexas   (ComplexAssembly) ;

•  módulos   (Module)  representam hierarquias de montagens complexas. Um módulo

possui um manual   (Manual)  e uma montagem complexa raiz;

•  manuais   (Manual)  representam a documentação de um módulo.

A implementação de OO7 desenvolvida nesta pesquisa adota o banco de dados

(modelo, índices e dados) da desenvolvida em (ZYL, 2010). A Seção B.2 exibe suas tabelas

principais. A Figura 72 exibe os comandos SQL que criam seus índices.

OO7 especifica três tamanhos de banco de dados: pequeno, médio e grande. Esta

pesquisa, tal como (IBRAHIM; COOK, 2006), adotou o tamanho pequeno. Nele, o banco

de dados é populado com 500 partes compostas, 10.000 partes atômicas, 30.000, 60.000 ou

90.000 conexões para cada parte atômica (esta pesquisa adotou 30.000), 729 montagens

básicas, 365 montagens complexas e 1 módulo.

Page 94: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 94/162

Capítulo 5. Avaliação   93

1   create index on   assembly ( des ign id ) ;

2   create index on   atomic_parts ( bui l ddat e ) ;

3   create index on   atomic_parts ( des ign id ) ;

4   create index on   composite_parts ( des ign id ) ;

5   create index on   document ( t i t l e ) ;6   create index on   module( bui ldda te ) ;

Figura 72 – Índices de OO7.

1   v is i t Atomi cPart=toConnections . to . v is it Atomi cPart ()   // T1

2   v i s i tA s s e m b l y = [

3   subAssemblies . v is i tAsse mbly ()

4   componentsPrivate . rootPart . v is it Atomi cPart ()

5   ]

6   des ignRoot . v is it Assem bly ()7

8   v i s i tA s s e m b l y = [   // T6 

9   subAssemblies . v is i tAsse mbly ()

10   componentsP rivate . root Part

11   ]

12   des ignRoot . v is it Assem bly ()

Figura 73 – Especificações  Litoral que fazem parte de OO7.

OO7 é composto por sete cenários denominados T1, T2, T3, T6, T8, T9 e CU

(Cache Update). Os cenários T2, T3 e CU realizam as mesmas navegações que T1 e,

adicionalmente, atualizam objetos. Os cenários T8 e T9 consistem em carregar um manual

e varrer o seu conteúdo (uma cadeia de caracteres). Como o interpretador de  Litoral

influencia apenas o desempenho de navegações, esta pesquisa, tal como (IBRAHIM; COOK,

2006), ignora T2, T3 e CU. Ela também ignora T8 e T9, já que estes cenários não oferecem

opotunidades para concorrência. A Figura 73 exibe as especificações  Litoral que declaram

as navegações executadas em T1 e T6. As duas especificações são executadas a partir

de um módulo. A Seção B.1 exibe as classes dos objetos pelos quais estas especificações

navegam.

5.2.1 Implementação Baseada no Hibernate

A implementação de OO7 baseada no Hibernate sofreu uma única otimização:

atributos do tipo II são carregados através de consultas que fazem uso do operador   i n

de SQL para carregar vários objetos, ou seja, a anotação   @BatchSize  foi adicionada aos

atributos anotados com   @OneToMany,   @ManyToOne e   @ManyToMany. A Figura 74 exibe otempo total de 10 execuções das especificações T1 e T6 com as versões não otimizada e

otimizada. A última é 91,5–91,8% mais rápida do que a primeira.

Page 95: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 95/162

Capítulo 5. Avaliação   94

Figura 74 – Resultados da otimização da implementação de  OO7  baseada no Hibernate.

5.2.2 Implementação Baseada no EclipseLink JPA

A implementação de OO7 baseada no EclipseLink JPA sofreu a mesma otimização

que a baseada no Hibernate. Entretanto, uma limitação do EclipseLink JPA impediu que

os objetos referenciados pelos atributos   componentsPrivate  da classe   BaseAssembly  e

subAssemblies  da classe   ComplexAssembly fossem carregados através de consultas que

fazem uso do operador   i n  de SQL para carregar vários objetos. Mais especificamente,

a exceção   o r g . e c l i p s e . p e r s i s te n c e . e x c e p t i o n s . Q u er y Ex c ep t io n  é levantada com

o código de erro   6169  quando a anotação   @BatchFetch( va lu e=BatchFetchType . IN)  é

adicionada a estes atributos.

5.2.3 Implementação Baseada no Interpretador de  Litoral

A implementação de OO7 baseada no interpretador de   Litoral sofreu a mesma

otimização que a baseada no Hibernate. Entretanto, diferentemente do Hibernate e do

EclipseLink JPA, ela não armazena objetos em um cache.

5.2.4 Resultados

A Figura 75 exibe o tempo total de execução das especificações T1 e T6 com as

implementações de OO7 baseadas no Hibernate, EclipseLink JPA e no interpretador de

Litoral. O tempo total de execução das especificações T1 e T6 com o interpretador no

modo concorrente foi 49,5–59,3% menor do que no sequencial.

O tempo total de execução das especificações T1 e T6 com o interpretador no

modo sequencial foi menor do que com as implementações baseadas no Hibernate e

EclipseLink JPA. A única exceção foi a especificação T6 com o Hibernate. Entretanto, o

tempo total de execução com o interpretador no modo concorrente foi menor do que com as

implementações baseadas no Hibernate (52,4–58,0%) e no EclipseLink JPA (95,2–96,5%).

Page 96: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 96/162

Capítulo 5. Avaliação   95

Figura 75 – Tempo total de execução das implementações de  Emeio baseadas no inter-

pretador de  Litoral, Hibernate e EclipseLink JPA.

No caso do Hibernate, a redução no tempo total de execução se deve majoritariamente à

execução concorrente de consultas. Entretanto, no caso do EclipseLink JPA, a contribuição

desta otimização foi minoritária, pois o tempo total de execução com o interpretador no

modo sequencial já é muito menor (90,4–91,5%) do que com o EclipseLink JPA.

Page 97: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 97/162

96

6 Trabalhos Relacionados

Este capítulo discute trabalhos (Program Summaries, Scalpel, AutoFetch, etc.) que,

assim como esta pesquisa, visam aumentar o desempenho de sistemas baseados em ORMs.

De maneira geral, eles alcançam este objetivo produzindo consultas SQL que, quando

executadas sequencialmente, minimizam o tempo de pré-carregamento de objetos. Um

aspecto interessante, evidenciado no Capítulo 5, é que estas consultas, na maioria dos

casos, também podem ser executadas concorrentemente, reduzindo ainda mais o tempo de

pré-carregamento de objetos.

6.1 Program Summaries

(GUÉHIS; GOASDOUÉ-THION; RIGAUX,  2009) aumenta o desempenho de

sistemas baseados em ORMs pré-carregando objetos com consultas que carregam vários

objetos. Para isto, ele define uma linguagem chamada Program Summary, baseada na

linguagem XPath (CLARK; DEROSE et al., 1999), que permite especificar navegações

por objetos. A Figura 76, por exemplo, exibe uma especificação Program Summary que

declara navegações das mensagens enviadas pelo usuário cujo identificador é igual a   1

para seus remetentes e destinatários.

Sejam  S  uma especificação Program Summary,  G  um grafo de objetos e   v  um

vértice deste grafo. (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) define formalmente

o traço T S,v(G) de S  sobre o vértice v com respeito a G. Intuitivamente, o traço corresponde

aos vértices de  G pelos quais a especificação  S , iniciando por  v, navega.

(GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) apresenta três estratégias para

transformar uma especificação Program Summary  S  em programas que, dados um grafo

de objetos  G e um vértice  v deste grafo, carregam  T S,v(G). Estes programas são formadospelas operações open, fetch e decode, consultas SQL e laços.

A primeira estratégia é chamada de Lazy e corresponde ao carregamento sob

demanda dos vértices de G. Esta estratégia, portanto, é a que executa mais consultas SQL.

1   @db. Message [ sender . id e n t i f i e r =1] {

2   @sender {} ;

3   @ r e c i p i e n t s { }

4   }

Figura 76 – Especificação Program Summary que declara navegações das mensagens envi-adas por um usuário para seus remetentes e destinatários.

Page 98: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 98/162

Capítulo 6. Trabalhos Relacionados    97

A segunda estratégia, chamada de Single, faz uso de junções (AHO; BEERI;

ULLMAN, 1979) e do operador   union  de SQL para carregar vários objetos executando

uma única consulta. A desvantagem desta estratégia é que o resultado da consulta que ela

executa tende a ter um número muito grande de linhas e colunas.A terceira estratégia é chamada de Decorrelation e executa uma consulta SQL para

cada tabela que contém vértices de  T S,v(G). Ela é uma estratégia intermediária entre a

Lazy e a Single, já que, como a Lazy, ela executa mais de uma consulta SQL e, como a

Single, ela executa consultas que carregam vários objetos.

(GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) define o custo de execução de

uma especificação Program Summary como sendo a combinação linear

C open ×N open + C net ×N fetch + C decode ×N decode

, onde  C open,  C net  e  C decode, são os pesos relativos das operações open, fetch e decode e

N open,  N net e  N decode são os números de vezes que estas operações são executadas.

Ele supõe que os pesos  C open,  C net e  C decode são similares e propõe um algoritmo

que transforma uma especificação Program Summary  S  em um programa que combina as

estratégias Lazy, Single e Decorrelation de forma a minimizar a soma N open+N fetch+N decode

e, portanto, minizar o custo de execução de  S .

Para avaliar sua proposta, (GUÉHIS; GOASDOUÉ-THION; RIGAUX,   2009)implementa uma extensão do Hibernate que aplica o algoritmo de otimização a uma

especificação Program Summary e pré-carrega seu traço. A partir desta extensão, ele

propõe e implementa um benchmark que adota o banco de dados do benchmark TPC-H

(POESS; FLOYD, 2000).

Em comum com esta pesquisa, (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009)

define uma linguagem que permite especificar navegações por objetos e projeta e implementa

um interpretador que executa especificações desta linguagem, pré-carregando os objetos

pelos quais ele navega.

Entretanto, uma diferença fundamental entre (GUÉHIS; GOASDOUÉ-THION;

RIGAUX, 2009) e esta pesquisa é que o primeiro se propõe a reduzir o tempo de pré-

carregamento   t p  de objetos encontrando as consultas que, quando executadas sequen-

cialmente, minimizam   t p, enquanto que esta pesquisa reduz   t p  executando consultas

concorrentemente.

Outras diferenças importantes são:

•   (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) define a sintaxe de Program

Summary a partir da sintaxe de um subconjunto de XPath, sem precisar que

subconjunto é este. Esta pesquisa define a sintaxe de  Litoral completamente;

Page 99: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 99/162

Page 100: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 100/162

Page 101: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 101/162

Capítulo 6. Trabalhos Relacionados    100

As restrições que AutoFetch impõe à estratégia Single evitam, na maioria dos casos,

que ela execute consultas que aumentam o tempo de pré-carregamento ao invés de reduzi-

lo. Entretanto, por adotar apenas uma variação da estratégia Single, o desempenho de

AutoFetch é, provavelmente, pior que o de Program Summaries nos casos em que este últimodetermina que a estratégia Single não é a que minimiza o tempo de pré-carregamento.

Em comum com Program Summaries e Scalpel, AutoFetch aumenta o desempenho

de sistemas baseados em ORMs agrupando consultas que são executadas sequencialmente.

Trata-se, portanto, de um trabalho relacionado, mas que explora uma otimização diferente

da proposta nesta pesquisa.

6.4 Outros Trabalhos sobre Pré-carregamento Especulativo

Esta seção relaciona outros trabalhos sobre pré-carregamento especulativo em

sistemas baseados em ORMs e similares que, assim como AutoFetch, focam em métodos de

especulação. Diferentemente desta pesquisa, nenhum deles pré-carrega objetos executando

consultas concorrentemente.

(HAN; WHANG; MOON, 2005; IBRAHIM; COOK, 2006): classificam estes traba-

lhos nas categorias a seguir.

Baseados em páginas: são aqueles que, tais como os OODBMs (Object-Oriented

Database Management Systems) Orion (KIM et al., 1990) e ObjectStore (LAMB et al.,

1991), pré-carregam objetos que estão armazenados em uma mesma página de memória;

Baseados em padrões de acesso a objetos/páginas: são aqueles que, ao

carregarem um objeto/página, pré-carregam outros objetos/páginas cujos acessos estão

correlacionados com os do primeiro. (PALMER, 1991) é um cache que implementa esta

técnica. (CUREWITZ; KRISHNAN; VITTER, 1993; VITTER; KRISHNAN, 1996) em-

pregam métodos de compressão de dados para identificar correlações. (GARBATOV;

CACHOPO, 2010; GARBATOV et al., 2011) empregam métodos estocásticos;

Baseados em contexto: (BERNSTEIN; PAL; SHUTT, 2000) foi o primeiro

trabalho deste tipo. A seção 2.3 discute o método de especulação que ele propôs, o qual

(HAN et al., 2001; HAN; MOON; WHANG, 2003; HAN; WHANG; MOON, 2005) refinaram

posteriormente.

Page 102: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 102/162

101

7 Conclusão

Esta pesquisa partiu da hipótese de que ORMs podem aumentar o desempenho de

sistemas executando concorrentemente consultas que pré-carregam objetos e se propôs a

desenvolver esta otimização.

As avaliações descritas no capítulo 5 são evidências de que a hipótese é verdadeira e

de que o desenvolvimento da otimização foi bem sucedido. De fato, no benchmark Emeio,

a execução concorrente de consultas reduziu o tempo total de execução em até 69,1%,

ou seja, aumentou a velocidade de execução em até 323,6%. Já no benchmark OO7, o

tempo total de execução foi reduzido em até 59,3%, ou seja, a velocidade de execução foiaumentada em até 245,7%.

Nos dois benchmarks, em todos os cenários que oferecem oportunidades para a

execução concorrente de consultas que pré-carregam objetos, o tempo total de execução com

esta otimização foi menor do que com importantes ORMs industriais, os quais executam

estas consultas apenas sequencialmente. Este resultado é mais uma evidência de que o

desempenho de sistemas baseados em ORMs será maior se estes últimos adotarem a

otimização proposta e desenvolvida nesta pesquisa.

7.1 Contribuições

As contribuições principais desta pesquisa foram:

1.   identificar a oportunidade de pré-carregar objetos pelos quais sistemas baseados em

ORMs navegam executando consultas concorrentemente;

2.  produzir evidências de que, explorando esta oportunidade, pode-se aumentar signifi-

cativamente o desempenho destes sistemas.

Adicionalmente, a forma como esta pesquisa explorou tal oportunidade produziu

as seguintes contribuições:

3.  a DSL  Litoral, a qual permite a especificação de navegações iterativas e recursivas

por objetos;

4. o interpretador definidor de  Litoral, o qual se aproxima de uma definição formal

desta DSL;

5.  o projeto e a implementação do interpretador de  Litoral, o qual pode ser facilmente

integrado a ORMs e outros mecanismos de carregamento de objetos;

Page 103: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 103/162

Capítulo 7. Conclusão   102

6.  o benchmark  Emeio, voltado para a avaliação de desempenho de navegações em

ORMs;

7.  o projeto e a implementação do framework  Afluentes (ARAUJO et al., 2014),

o qual permite que sistemas que executam operações de E/S sequencialmente ou

concorrentemente através de primitivas de E/S síncronas ou assíncronas sejam

desenvolvidos com um mesmo modelo de programação.

7.2 Trabalhos Futuros

Possíveis desdobramentos desta pesquisa são:

1. identificar e explorar outras oportunidades de aumentar o desempenho de sistemasbaseados em ORMs através da execução concorrente de consultas;

2.  produzir mais evidências de que sistemas baseados em ORMs oferecem oportuni-

dades para pré-carregar os objetos pelos quais eles navegam executando consultas

concorrentemente e que explorando esta oportunidade aumenta-se o desempenho

destes sistemas;

3.  evoluir modelos de custos de carregamento de objetos tais como o de ( GUÉHIS;

GOASDOUÉ-THION; RIGAUX, 2009) para levar em conta a concorrência, pois asconsultas que minimizam o tempo de carregamento de objetos quando executadas

sequencialmente podem não gozar desta propriedade quando executadas concorren-

temente.

O segundo desdobramento pode ser conduzido aplicando-se o mesmo método desta

pesquisa, ou seja, implementando benchmarks sintéticos com um ORM mínimo integrado

ao interpretador de  Litoral e também com ORMs industriais e, em seguida, comparando

o desempenho das implementações.Uma alternativa consiste em integrar o interpretador de  Litoral  a um ORM

popular. Apesar desta alternativa demandar um esforço inicial maior, ela tem a grande

vantagem de permitir que a otimização desenvolvida nesta pesquisa seja avaliada com

qualquer sistema baseado no ORM com o qual o interpretador de Litoral foi integrado.

Outra alternativa consiste em registrar as consultas que sistemas baseados em

ORMs executam para pré-carregar objetos e analisar quais delas podem ser executadas

concorrentemente. Por fim, simula-se a execução sequencial e concorrente das consultas. A

partir do tempo total de execução de cada simulação é possível estimar os efeitos que aotimização desenvolvida nesta pesquisa terá sobre os sistemas.

Page 104: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 104/162

103

Referências

ADYA, A. et al. Anatomy of the ado. net entity framework. In: ACM. Proceedings of the 2007 ACM SIGMOD international conference on Management of data . [S.l.], 2007. p.877–888. Citado na página 19.

AHO, A. V.; BEERI, C.; ULLMAN, J. D. The theory of joins in relational databases.ACM Transactions on Database Systems (TODS), ACM, v. 4, n. 3, p. 297–314, 1979.Citado 2 vezes nas páginas 27  e  97.

ARAUJO, S. M. d. et al. Afluentes concurrent i/o made easy with lazy evaluation. In:IEEE.  Parallel, Distributed and Network-Based Processing (PDP), 2014 22nd Euromicro

International Conference on . [S.l.], 2014. p. 279–287. Citado 3 vezes nas páginas 20, 61e 102.

ARMBRUST, M. et al. A view of cloud computing.  Communications of the ACM , ACM,v. 53, n. 4, p. 50–58, 2010. Citado na página 31.

BERNSTEIN, P. A.; PAL, S.; SHUTT, D. Context-based prefetch–an optimization forimplementing objects on relations.  The VLDB Journal , Springer-Verlag, v. 9, n. 3, p.177–189, 2000. Citado 5 vezes nas páginas 17,  30,  31, 83  e 100.

BERTOT, Y.; CASTÉRAN, P.  Interactive theorem proving and program development .[S.l.]: Springer Science & Business Media, 2004. Citado 2 vezes nas páginas 20 e  41.

BLAKELEY, J. A. et al. The ado. net entity framework: making the conceptual level real.ACM SIGMOD Record , ACM, v. 35, n. 4, p. 32–39, 2006. Citado na página 19.

BONCZ, P. A.; KWAKKEL, F.; KERSTEN, M. L. High performance support for ootraversals in monet. CWI (Centre for Mathematics and Computer Science), 1995. Citadona página 83.

BOWMAN, I. T.; SALEM, K. Optimization of query streams using semantic prefetching.ACM Transactions on Database Systems (TODS), ACM, v. 30, n. 4, p. 1056–1101, 2005.Citado na página 98.

BOWMAN, I. T.; SALEM, K. Semantic prefetching of correlated query sequences. In:IEEE. Data Engineering, 2007. ICDE 2007. IEEE 23rd International Conference on .[S.l.], 2007. p. 1284–1288. Citado 2 vezes nas páginas 27 e  98.

CAREY, M. J. et al. A status report on the oo7 oodbms benchmarking effort.  ACM SIGPLAN Notices , ACM, v. 29, n. 10, p. 414–426, 1994. Citado 2 vezes nas páginas 20e 83.

CAREY, M. J.; DEWITT, D. J.; NAUGHTON, J. F.  The 007 benchmark . [S.l.]: ACM,1993. Citado 2 vezes nas páginas 20 e  83.

CASTRO, P.; MELNIK, S.; ADYA, A. Ado. net entity framework: raising the level of abstraction in data programming. In: ACM.  Proceedings of the 2007 ACM SIGMOD international conference on Management of data . [S.l.], 2007. p. 1070–1072. Citado napágina 19.

Page 105: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 105/162

Referências    104

CLARK, J.; DEROSE, S. et al. Xml path language (xpath).  W3C recommendation , v. 16,1999. Citado na página 96.

CUREWITZ, K. M.; KRISHNAN, P.; VITTER, J. S. Practical prefetching via data

compression.  ACM SIGMOD Record , ACM, v. 22, n. 2, p. 257–266, 1993. Citado napágina 100.

CURNOW, H. J.; WICHMANN, B. A. A synthetic benchmark.  The Computer Journal ,Br Computer Soc, v. 19, n. 1, p. 43–49, 1976. Citado na página 20.

DEURSEN, A. V.; KLINT, P.; VISSER, J. Domain-specific languages: An annotatedbibliography.  Sigplan Notices , v. 35, n. 6, p. 26–36, 2000. Citado na página 18.

EISENBERG, A. et al. Sql: 2003 has been published.  ACM SIGMoD Record , ACM, v. 33,n. 1, p. 119–126, 2004. Citado na página 17.

FIELDING, R. T.; TAYLOR, R. N. Principled design of the modern web architecture.ACM Transactions on Internet Technology (TOIT), ACM, v. 2, n. 2, p. 115–150, 2002.Citado na página 20.

FOUNDATION, E. Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation . 2008. Disponível em:  <http://www.eclipse.org/org/press-release/20080317_Eclipselink.php>.  Citado na página 20.

GAMMA, E. et al.   Design Patterns: Elements of Reusable Object-Oriented Software . Pearson Education, 1994. ISBN 9780321700698. Disponível em:  <http://books.google.com.br/books?id=6oHuKQe3TjQC> . Citado na página 28.

GARBATOV, S.; CACHOPO, J. Predicting data access patterns in object-orientedapplications based on markov chains. In: IEEE.  Software Engineering Advances (ICSEA),2010 Fifth International Conference on . [S.l.], 2010. p. 465–470. Citado na página 100.

GARBATOV, S. et al. Data access pattern analysis and prediction for object-orientedapplications. INFOCOMP Journal of Computer Science , v. 10, n. 4, p. 1–14, 2011. Citadona página 100.

GERSEN, C. M.  ORM Optimization through Automatic Prefetching in WebDSL.Dissertação (Mestrado) — Delft University of Technology, 2013. Citado na página 83.

GEUVERS, H. Proof assistants: History, ideas and future. Sadhana , Springer, v. 34, n. 1,p. 3–25, 2009. Citado 2 vezes nas páginas 20  e  41.

GOSLING, J. et al.  The Java Language Specification, Java SE 8 Edition . PearsonEducation, 2014. ISBN 9780133900798. Disponível em: <http://books.google.com.br/books?id=1DaDAwAAQBAJ>. Citado na página 16.

GROUP, J. P. . E. JSR 338: Java TM  Persistence API, Version 2.1. 2013. Disponível em:<http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html>.Citado 2 vezes nas páginas 20  e  25.

GUÉHIS, S.; GOASDOUÉ-THION, V.; RIGAUX, P. Speeding-up data-driven applicationswith program summaries. In: ACM.   Proceedings of the 2009 International Database Engineering & Applications Symposium . [S.l.], 2009. p. 66–76. Citado 5 vezes nas páginas19, 96, 97, 98 e  102.

Page 106: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 106/162

Referências    105

GUERRAOUI, R.; KAPALKA, M.; VITEK, J. Stmbench7: A benchmark forsoftware transactional memory. In:   Proceedings of the 2Nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007 . New York, NY, USA: ACM,2007. (EuroSys ’07), p. 315–324. ISBN 978-1-59593-636-3. Disponível em:

<http://doi.acm.org/10.1145/1272996.1273029> . Citado na página 83.

HAN, W.-S.; MOON, Y.-S.; WHANG, K.-Y. Prefetchguide: capturing navigationalaccess patterns for prefetching in client/server object-oriented/object-relational dbmss.Information Sciences , Elsevier, v. 152, p. 47–61, 2003. Citado na página 100.

HAN, W.-S.; WHANG, K.-Y.; MOON, Y.-S. A formal framework for prefetching based onthe type-level access pattern in object-relational dbmss.  Knowledge and Data Engineering,IEEE Transactions on , IEEE, v. 17, n. 10, p. 1436–1448, 2005. Citado 2 vezes naspáginas 83 e  100.

HAN, W.-S. et al. Prefetching based on the type-level access pattern in object-relationaldbmss. In: IEEE.  Data Engineering, 2001. Proceedings. 17th International Conference on .[S.l.], 2001. p. 651–660. Citado na página 100.

HAROLD, E.  Java I/O . O’Reilly Media, 2006. ISBN 9781449390884. Disponível em:<http://books.google.com.br/books?id=42etT\_9-\_9MC>.  Citado na página 61.

HOVEMEYER, D.; SPACCO, J.; PUGH, W. Evaluating and tuning a static analysis tofind null pointer bugs. In: ACM.  ACM SIGSOFT Software Engineering Notes . [S.l.], 2005.v. 31, n. 1, p. 13–19. Citado na página 32.

IBRAHIM, A.; COOK, W. R. Automatic prefetching by traversal profiling in objectpersistence architectures. ECOOP 2006–Object-Oriented Programming , Springer BerlinHeidelberg, p. 50–73, 2006. Citado 7 vezes nas páginas 19, 34, 83,  92,  93,  99  e  100.

IBRAHIM, A.; WIEDERMANN, B.; COOK, W. R. Coordinating database andprogramming language research. In: CITESEER.  ESSAY SUBMITTED TO CIDR 2009 MONTEREY, CALIFORNIA USA. [S.l.], 2009. Citado na página 30.

JR, R. L. B. et al. Safe nondeterminism in a deterministic-by-default parallel language. In:ACM.  ACM SIGPLAN Notices . [S.l.], 2011. v. 46, n. 1, p. 535–548. Citado na página 83.

KEITH, M.; SCHINCARIOL, M. Pro jpa 2. Mastering the Java Persistence API , Springer,2009. Citado na página 20.

KIM, W. et al. Architecture of the orion next-generation database system.  Knowledge and Data Engineering, IEEE Transactions on , IEEE, v. 2, n. 1, p. 109–124, 1990. Citado napágina 100.

LAMB, C. et al. The objectstore database system.  Communications of the ACM , ACM,v. 34, n. 10, p. 50–63, 1991. Citado na página 100.

LEA, D. A java fork/join framework. In: ACM.  Proceedings of the ACM 2000 conference on Java Grande . [S.l.], 2000. p. 36–43. Citado 2 vezes nas páginas 61  e  62.

LI, Y. G. et al. Xoo7: applying oo7 benchmark to xml query processing tool. In:ACM.  Proceedings of the tenth international conference on Information and knowledge management . [S.l.], 2001. p. 167–174. Citado na página 83.

Page 107: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 107/162

Referências    106

LINSKEY, P. C.; PRUD’HOMMEAUX, M. An in-depth look at the architecture of anobject/relational mapper. In: ACM.  Proceedings of the 2007 ACM SIGMOD international conference on Management of data . [S.l.], 2007. p. 889–894. Citado na página 19.

MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specificlanguages. ACM computing surveys (CSUR), ACM, v. 37, n. 4, p. 316–344, 2005. Citado2 vezes nas páginas 32 e  71.

MEYEROVICH, L. A. et al. Flapjax: a programming language for ajax applications. In:ACM.  ACM SIGPLAN Notices . [S.l.], 2009. v. 44, n. 10, p. 1–20. Citado na página 35.

MILNER, R.  The definition of standard ML: revised . [S.l.]: MIT press, 1997. Citado napágina 41.

NANZ, S.; WEST, S.; SILVEIRA, K. S. D. Examining the expert gap in parallel

programming. In: Euro-Par 2013 Parallel Processing . [S.l.]: Springer, 2013. p. 434–445.Citado na página 18.

O’NEIL, E. J. Object/relational mapping 2008: hibernate and the entity data model(edm). In: ACM.  Proceedings of the 2008 ACM SIGMOD international conference on Management of data . [S.l.], 2008. p. 1351–1356. Citado 2 vezes nas páginas 19 e  20.

PALMER, M. S. zdonik,“fido: A cache that learns to fetch,”. In:  Proceedings of the 1991International Conference on Very Large Databases . [S.l.: s.n.], 1991. Citado na página100.

PARR, T.  The definitive ANTLR reference: building domain-specific languages . [S.l.]:

Pragmatic Bookshelf, 2007. Citado na página 74.

PARR, T. J.; QUONG, R. W. Antlr: A predicated-ll (k) parser generator.   Software:Practice and Experience , Wiley Online Library, v. 25, n. 7, p. 789–810, 1995. Citado napágina 74.

PEIERLS, T. et al.   Java Concurrency in Practice . Pearson Education, 2006. ISBN9780132702256. Disponível em:  <http://books.google.com.br/books?id=EK43StEVfJIC>.Citado na página 61.

PINTER, C. A Book of Abstract Algebra: Second Edition . Dover Publications, 2012. ISBN

9780486134796. Disponível em:  <https://books.google.com.br/books?id=qviuEUavE4IC>.Citado na página 115.

POESS, M.; FLOYD, C. New tpc benchmarks for decision support and web commerce.ACM Sigmod Record , ACM, v. 29, n. 4, p. 64–71, 2000. Citado na página 97.

REYNOLDS, J. C. Definitional interpreters for higher-order programming languages.In: ACM.  Proceedings of the ACM annual conference-Volume 2 . [S.l.], 1972. p. 717–740.Citado 2 vezes nas páginas 20  e  41.

ROY, P. V. et al. Programming paradigms for dummies: What every programmer should

know.  New computational paradigms for computer music , IRCAM/Delatour France,v. 104, 2009. Citado 2 vezes nas páginas 41  e  61.

Page 108: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 108/162

Referências    107

RYMAN, A. Simple object access protocol (soap) and web services. In: IEEE COMPUTERSOCIETY.  Software Engineering, International Conference on . [S.l.], 2001. p. 0689–0689.Citado na página 20.

SCOTT, M.   Programming Language Pragmatics . Morgan Kaufmann, 2006.(Programming Language Pragmatics, v. 1). ISBN 9780126339512. Disponível em:<http://books.google.com.br/books?id=TLbvODF1uIEC>.  Citado na página 62.

SIPELSTEIN, J. M.; BLELLOCH, G. E. Collection-oriented languages.  Proceedings of the IEEE , IEEE, v. 79, n. 4, p. 504–523, 1991. Citado na página 32.

SUBRAMANIAM, V.   Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions . Pragmatic Programmers, LLC, 2014. (Pragmaticprogrammers). ISBN 9781937785468. Disponível em:  <http://books.google.com.br/books?id=4Y7TngEACAAJ>.  Citado na página 63.

TANENBAUM, A.  Modern Operating Systems . Pearson Prentice Hall, 2008. (GOALSeries). ISBN 9780136006633. Disponível em:  <http://books.google.com.br/books?id=DxNiQgAACAAJ>. Citado na página 22.

THOMSON, B.; BRUCKNER, J.; BRUCKNER, A. Elementary Real Analysis, Second Edition . Createspace Independent Pub, 2008. ISBN 9781434843678. Disponível em:<http://books.google.com.br/books?id=vA9d57GxCKgC> . Citado 3 vezes nas páginas50, 57 e  115.

VITTER, J. S.; KRISHNAN, P. Optimal prefetching via data compression. Journal of the 

ACM (JACM), ACM, v. 43, n. 5, p. 771–793, 1996. Citado na página 100.WALDO, J. Remote procedure calls and java remote method invocation.  Concurrency,IEEE , IEEE, v. 6, n. 3, p. 5–7, 1998. Citado na página 20.

WELC, A.; JAGANNATHAN, S.; HOSKING, A. Safe futures for java. In: ACM.  ACM SIGPLAN Notices . [S.l.], 2005. v. 40, n. 10, p. 439–453. Citado na página 83.

WITT, D. J. D. et al. Parallelizing oodbms traversals: a performance evaluation.  the VLDB Journal , Springer, v. 5, n. 1, p. 3–18, 1996. Citado na página 83.

ZIAREK, L. et al. A uniform transactional execution environment for java. In:   ECOOP 

2008–Object-Oriented Programming . [S.l.]: Springer, 2008. p. 129–154. Citado na página83.

ZYL, P. V.  Performance investigation into selected object persistence stores . Dissertação(Mestrado) — University of Pretoria, 2010. Citado 2 vezes nas páginas 83 e  92.

ZYL, P. V.; KOURIE, D. G.; BOAKE, A. Comparing the performance of objectdatabases and orm tools. In: SOUTH AFRICAN INSTITUTE FOR COMPUTERSCIENTISTS AND INFORMATION TECHNOLOGISTS. Proceedings of the 2006 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries . [S.l.], 2006. p. 1–11. Citado na

página 83.

Page 109: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 109/162

Page 110: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 110/162

109

APÊNDICE A –   Emeio

A.1 Classes

1   import   jav a . u t i l . Date ;

2   import   java . ut i l . Lis t ;

3

4   c l a s s   Message {

5   p ri v at e i n t   i d ;

6   private   Date date ;

7   private  S t r i n g s u b j e c t ;

8   private   Str ing body ;

9   private   User sender ;

10   private   L i s t<U se r> r e c i p i e n ts ;

11   private   List <File> attachments ;

12   private   L ist<Message> re pl ie s ;

13   private   List<Tag> tags ;

14

15   void   s e t I d ( i n t   i d ) {

16   t h i s  . i d = i d ;

17   }

18

19   i nt   g e t I d ( ) {

20   return   i d ;

21   }

22

23   // Demais m ét od os s e t e g e t  

24   }

25

26   c l a s s   U s e r {

27   p ri v at e i n t   i d ;

28   private   Str ing name;

29   private   F i l e p i c t u r e ;

30

31   // Mét odos s e t e g e t  

32   }

33

34   c l a s s   F i l e {

35   p ri v at e i n t   i d ;

36   private   Str ing name;

37   private   MediaType mediaType ;

38

39   // Mét odos s e t e g e t  

40   }

Page 111: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 111/162

Page 112: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 112/162

Page 113: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 113/162

112

APÊNDICE B – OO7

B.1 Classes

1   import   java . ut i l . Lis t ;

2

3   c l a s s   CompositePart {

4   p riva te lo ng   compositePartId ;

5   p riva te lo ng   buildDate ;

6   p ri v at e i n t   d e s i g n Id ;

7   private  S t r i n g t y pe ;

8   private   AtomicPart rootPart ;

9

10   // Mét odos s e t e g e t  

11   }

12

13   c l a s s   AtomicPart {

14   p riva te lo ng   atomicPartId ;

15   p riva te lo ng   buildDate ;

16   p ri v at e i n t   d e s i g n Id ;

17   private   S t r i n g t y pe ;

18   private   List <Connection> toConnections ;

19

20   // Mét odos s e t e g e t  

21   }

22

23   c l a s s   Connection {

24   p riva te lo ng   c o n n e c t i o n Id ;

25   p ri v at e i n t   l engt h ;

26   private   S t r i n g t y pe ;

27   private   AtomicPart to ;

28

29   // Mét odos s e t e g e t  

30   }

31

32   c l a s s   Assembly {

33   p riva te lo ng   assembl yId ;

34   p riva te lo ng   buildDate ;

35   p ri v at e i n t   d e s i g n Id ;

36   private   S t r i n g t y pe ;

37

38   // Mét odos s e t e g e t  

39   }

40

Page 114: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 114/162

APÊNDICE B. OO7    113

41   c l a s s   BaseAssembly   extends   Assembly {

42   private   Lis t<CompositePart> componentsP rivate ;

43

44   // Mét odos s e t e g e t  

45   }46

47   c l a s s   ComplexAssembly   extends   Assembly {

48   private   Lis t<JpaAssembly> subAs sembli es ;

49

50   // Mét odos s e t e g e t  

51   }

Page 115: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 115/162

APÊNDICE B. OO7    114

B.2 Tabelas

Figura 78 – Tabelas de OO7.

Page 116: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 116/162

Page 117: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 117/162

APÊNDICE C. Demonstrações    116

18   Proof .

19   un fo ld nonDecNatSeq .

20   un fo ld nonDecNatSeq2 .

21   i n t r o s .

22   i n d u c t i o n n ’ .23   {

24   a s s er t ( n = 0 ) .

25   {

26   omega.

27   }

28   r e w r i t e H1 .

29   aut o .

30   }

31   {

32   a s s e r t ( n <= n ’ \ / n = S n ’ ) .33   {

34   omega.

35   }

36   d e s t r u c t H1 .

37   {

38   a s s e r t ( f n <= f n ’ ) .

39   {

40   aut o .

41   }

42   a s s e r t ( f n ’ <= f ( S n ’ ) ) .43   {

44   aut o .

45   }

46   omega.

47   }

48   {

49   r e w r i t e H1 . a ut o .

50   }

51   }

52   Qed .53

54   Theorem   nonDecBndNatSeqConvSeq :

55   f o r a l l f , no nDecNa tS eq f    −> bndNatSeq f    −> convSeq f .

56   Proof .

57   unf old bndNatSeq .

58   unfo ld convSeq .

59   unfo ld consSeq .

60   u n f o l d s u f f S e q .

61   i n t r o s .

62   d e s t r u c t H0 a s [ L ] .63   i n d u ct i o n L .

64   {

Page 118: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 118/162

APÊNDICE C. Demonstrações    117

65   e x i st s 0 .

66   i n t r o s .

67   a s s e r t ( f ( 0 + n ) <= 0 ) .

68   {

69   auto .70   }

71   a s s e r t ( f ( 0 + S n ) <= 0 ) .

72   {

73   auto .

74   }

75   omega.

76   }

77   {

78   d es t ru ct ( c l a s s i c ( f o r a l l n : nat , f n <= L ) ) .

79   {80   auto .

81   }

82   {

83   a s s e r t ( e x i s t s N, ~ f N <= L ) .

84   {

85   apply not_all_ex_not .

86   aut o .

87   }

88   d e s t r u c t H2 a s [ N ] .

89   e x i s t s N.90   i n t r o s .

91   a s s e r t ( f N <= f (N + n ) ) .

92   {

93   app ly nonDecNatSeqNonDecNatSeq2   in   H.

94   unf old nonDecNatSeq2   in   H.

95   a s s e r t (N <= N + n  −> f N <= f (N + n ) ) .

96   {

97   aut o .

98   }

99   apply H.100   omega.

101   }

102   a s s e r t ( f (N + n ) <= f (N + S n ) ) .

103   {

104   unf old nonDecNatSeq   in   H.

105   a s s e r t ( f (N + n ) <= f ( S (N + n ) ) ) .

106   {

107   aut o .

108   }

109   a s s e r t ( S (N + n ) = N + S n ) .110   {

111   omega.

Page 119: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 119/162

APÊNDICE C. Demonstrações    118

112   }

113   r e w r i t e <−   H5 .

114   aut o .

115   }

116   a s s e r t ( f (N + S n ) <= S L ) .117   {

118   aut o .

119   }

120   omega.

121   }

122   }

123   Qed .

C.3 ListSeq1   S e t Im p l i c i t A rg um en ts .

2

3   Require Import   L i s t .   Import   L i s tN o ta t i o n s .

4

5   Require Import   NatSeq .

6   Require Import  Seq .

7

8   Definition   L i s tS e q E := S eq ( l i s t E) .

9

10   Definition   s u f f E q L i s t E ( l l ’ : l i s t E) := e x i s t s l ’ ’ , l ’ = l ’ ’ ++ l .

11

12   Definition   n o nD ec Li st Se q E ( f : L i s t S e q E ) :=

13   f o r a l l n , s u ff E qL i st ( f n ) ( f ( S n ) ) .

14

15   Definition   l en gt hS eq E ( f : L i st S eq E) n := l e ng t h ( f n ) .

16

17   Definition   l e n g th Bn d L i stS e q E ( f : L i s tS e q E) : = b n dN atSe q ( l e n g th S e q f ) .

18

19

  Theorem   nonDecListSeqNonDecLengthSeq :20   f o r a l l E ( f : L i s tS e q E) , n on De cL is tS eq f    −> nonDecNatSeq ( lengthSeq f ) .

21   Proof .

22   unfo ld nonDecListSeq .

23   un fo ld nonDecNatSeq .

24   u n fo l d s u f f E q L i s t .

25   u n f o l d l e n g th S e q .

26   i n t r o s .

27   a s s e r t ( e x i s t s l ’ ’ , f ( S n ) = l ’ ’ ++ f n ) .

28   {

29

  aut o .30   }

31   d e s t r u c t H0 .

32   r e w r i t e H0 .

Page 120: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 120/162

APÊNDICE C. Demonstrações    119

33   a s s e r t ( l e n gt h ( x ++ f n ) = l e ng t h x + l e n gt h ( f n ) ) .

34   {

35   apply app_length .

36   }

37   omega.38   Qed .

39

40   Theorem   l en gt hZ er oE mp ty Li st : f o r a l l E ( l : l i s t E ) , l e n gt h l = 0   −> l = [ ] .

41   Proof .

42   i n t r o s .

43   u n f o l d l e n g t h   in   H.

44   d e s t r u ct l .

45   {

46   aut o .

47   }48   {

49   congruen ce .

50   }

51   Qed .

52

53   Theorem   nonDecLengthBndListSeqConv :

54   f o r a l l E ( f : L is tS eq E) ,

55   nonDecListSeq f    −> l e n gth Bn d L i stS e q f    −> convSeq f .

56   Proof .

57   unfo ld convSeq .58   unfo ld consSeq .

59   u n f o l d s u f f S e q .

60   i n t r o s .

61   a s s e r t ( c o nv Se q ( l e n gt h S e q f ) ) .

62   {

63   app ly nonDecBndNatSeqConvSeq .

64   apply nonDecListSeqNonDecLengthSeq .

65   aut o .

66   aut o .

67   }68   u n f o l d c on vS eq   in   H1 .

69   u n f o l d c o ns S e q   in   H1 .

70   u n fo l d s u f f S e q   in   H1 .

71   u n f o l d l e n gt h S e q   in   H1 .

72   d e s t r u c t H1 as [ N ] .

73   e x i s t s N.

74   i n t r o s .

75   a s s e r t ( e x i s t s l ’ ’ , f (N + S n ) = l ’ ’ ++ f (N + n ) ) .

76   {

77   a s s e r t ( e x i s t s l ’ ’ , f ( S (N + n ) ) = l ’ ’ ++ f (N + n ) ) .78   {

79   unfo ld nonDecListSeq   in   H.

Page 121: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 121/162

APÊNDICE C. Demonstrações    120

80   u n fo l d s u f f E q L i s t   in   H.

81   auto .

82   }

83   a s s e r t ( S (N + n ) = N + S n ) .

84   omega.85   r e w r i t e <−   H3 .

86   aut o .

87   }

88   d e s tr u c t H2 a s [ l ’ ’ ] .

89   a s s e r t ( l ’ ’ = [ ] ) .

90   {

91   a s s e r t ( l e n gt h l ’ ’ = 0 ) .

92   {

93   a s s e r t ( l e ng t h ( f (N + n ) ) = l e ng t h ( f (N + S n ) ) ) .

94   {95   aut o .

96   }

97   r e w r i t e H2   in   H3 .

98   r e wr i te a p p_ le ng th   in   H3 .

99   omega.

100   }

101   apply lengthZeroEmptyList .

102   aut o .

103   }

104   r e w r i t e H3   in   H2 .105   auto .

106   Qed .

C.4 Lim

1   S e t Im p l i c i t A rg um en ts .

2

3   Require Import   Omega.

4

5   Require Import  Seq .

6

7   Definition   l im Y ( f : Seq Y) L : = e x i s t s N, f o r a l l n , s u ff S eq f N n = L .

8

9   Theorem   s uf f S eq L im :

10   f o r a l l Y ( f : Seq Y) N L , l im ( s u ff S eq f N) L  −> lim f L .

11   Proof .

12   u n f o l d l i m .

13   u n f o l d s u f f S e q .

14

  i n t r o s .15   d e s t r u c t H a s [ N ’ ] .

16   e x i s t s (N + N ’ ) .

17   i n t r o s .

Page 122: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 122/162

APÊNDICE C. Demonstrações    121

18   a s s e r t (N + N ’ + n = N + ( N’ + n ) ) .

19   {

20   omega.

21   }

22   r e w r i t e H0 .23   auto .

24   Qed .

C.5 ListOptionSeq

1   S e t Im p l i c i t A rg um en ts .

2

3   Require Import   C l a s s i c a l .

4

  Require Import   L i s t .   Import   L i s tN o ta t i o n s .5

6   Require Import   Lim.

7   Require Import   ListS eq .

8   Require Import  Seq .

9

10   Definition   L i s tO p t io n S e q E := S eq ( o p t i o n ( l i s t E) ) .

11

12   Definition   s u f f L i s t O p t i on E ( l o l o ’ : o p ti o n ( l i s t E ) ) :=

13   match   lo ’   with

14

  | None => lo = None15   | Some [ ] => lo = Some [ ]

16   | Some l ’ => e x i s t s l e , l o = Some l /\ l ’ = e : : l

17   end .

18

19   Definition   d e c L i st O p ti o nS e q E ( f : L i s tO p ti o n Se q E ) :=

20   f o r a l l n , s u ff L is t Op t io n ( f ( S n ) ) ( f n ) .

21

22   Theorem   decOptionListSeqLim :

23   f o r a l l E ( f : L i st Op t io nS eq E ) ,

24

  d e c L i s tOp t i o n S e q f    −> l i m f None \ / l i m f ( Some [ ] ) .25   Proof .

26   i n t r o s .

27   d e s t r u ct ( c l a s s i c ( e x i s t s N , f N = None ) ) .

28   {

29   l e f t .

30   u n f o l d l i m .

31   u n f o l d s u f f S e q .

32   d e s t r u c t H0 a s [ N ] .

33   e x i s t s N.

34

  i n d u ct i o n n .35   {

36   a s s e r t (N + 0 = N ) .

37   {

Page 123: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 123/162

APÊNDICE C. Demonstrações    122

38   aut o .

39   }

40   r e w r i t e H1 .

41   auto .

42   }43   {

44   a s s e r t (N + S n = S (N + n ) ) .

45   {

46   omega.

47   }

48   r e w r i t e H1 .

49   u n f o l d d e c L i s tOp t i o n S e q   in   H.

50   u n fo l d s u f f L i s t O p t i on   in   H.

51   s p e c i a l i z e H   with   (N + n ) .

52   r e w r i t e IHn   in   H.53   auto .

54   }

55   }

56   {

57   a s s e r t ( f o r a l l n , f n <> None ) .

58   {

59   i n t r o s .

60   d e s t r u c t ( f n ) e qn : E1 .

61   {

62   congruen ce .63   }

64   {

65   u n f o l d n ot   in   H0 .

66   a s s e r t ( e x i s t s N : n at , f N = None ) .

67   {

68   e x i st s n .

69   aut o .

70   }

71   c o n t r a d i c t i o n .

72   }73   }

74

75   d e s t r u c t ( f 0 ) e qn : E1 .

76   {

77   a ss e rt (

78   f o r a l l n , e x i s t s l ’ , f n = Some l ’ /\ l e ng th l ’ = l en gt h l   −   n

79   ) .

80   {

81   i n d u ct i o n n .

82   {83   e x i s t s l .

84   a s s e r t ( l en g th l   −   0 = l e ng t h l ) .

Page 124: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 124/162

Page 125: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 125/162

APÊNDICE C. Demonstrações    124

132   d e s t r u c t IHn .

133   d e s t r u c t H6 .

134   i n j e c t i o n H6 .

135   i n t r o s .

136   r e w r i t e <−   H4 .137   r e w r i t e <−   H7 .

138   r e w r i t e <−   H8 .

139   s impl .

140   omega.

141   }

142   }

143   }

144   {

145   congruenc e .

146   }147   }

148   }

149

150   {

151   r i g h t .

152   u n f o l d l i m .

153   e x i s t s ( l e ng t h l ) .

154   i n t r o s .

155   s p e c i a l i z e H2   with   ( l en g th l + n ) .

156   d e s t r u c t H2 .157   d e s t r u c t H2 .

158   a s s e r t ( l e ng t h x = 0 ) .

159   {

160   omega.

161   }

162   apply lengthZeroEmptyList   in   H4 .

163   r e w r i t e H4   in   H2 .

164   u n f o l d s u f f S e q .

165   aut o .

166   }167   }

168   {

169   congruen ce .

170   }

171   }

172   Qed .

173

174   Theorem   d e cO p ti o n L is tS u f f S eq L i m :

175   f o r a l l E ( f : L i st Op t io nS eq E) N,

176   d e cL i s tO p t io n S eq ( s u f f S e q f N)   −> l i m f None \ / l i m f ( Some [ ] ) .177   Proof .

178   i n t r o s .

Page 126: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 126/162

APÊNDICE C. Demonstrações    125

179   apply decOptionListSeqLim   in   H.

180   d e s t r u c t H .

181   {

182   l e f t .

183   a p pl y s u f f S eq L i m   with   N.184   aut o .

185   }

186   {

187   r i g h t .

188   a p pl y s u f f S eq L i m   with   N.

189   aut o .

190   }

191   Qed .

192

193   Theorem   hasDecOptionListSuffSeqLim :194   f o r a l l E ( f : L i st Op t io nS eq E ) ,

195   ( e x i s t s N, d e cL i s tO p t io n S eq ( s u f f S e q f N) )   −> l i m f None \ /

196   l im f (Some [ ] ) .

197   Proof .

198   i n t r o s .

199   d e s t r u ct H a s [ N ] .

200   a p p ly d e c O p ti o n L i s tSu f f S e q L im   with   N.

201   auto .

202   Qed .

C.6 Sublist

1   S e t Im p l i c i t A rg um en ts .

2

3   Require Import   L i s t .   Import   L i s tN o ta t i o n s .

4   Require Import   Omega.

5

6   Require Import   ListS eq .

7

  Require Import   NatSeq .8   Require Import  Seq .

9

10   Definition   R e l E : = E  −> E  −> bool .

11

12   Definition   r e f l E ( f : Rel E) := f o r a l l e , f e e = tr ue .

13

14   Definition   symm E ( f : Rel E ) := f o r a l l e e ’ , f e e ’ = f e ’ e .

15

16   Definition   t r an s E ( f : Rel E ) :=

17

  f o r a l l e e ’ e ’ ’ , f e e ’ = t r ue   −> f e ’ e ’ ’ = f e e ’ ’ .18

19   Definition   e q ui E ( f : Rel E) := r e f l f /\ symm f /\ t r an s f .

20

Page 127: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 127/162

APÊNDICE C. Demonstrações    126

21   Fixpoint   c ou nt E ( r : Rel E ) l e :=

22   match   l   with

23   | [ ] => 0

24   | e ’ : : l ’ =>

25   l e t   co un t ’ := c ou nt r l ’ e   in

26   i f    r e e ’   then   S count ’   e l s e   count ’

27   end .

28

29   Definition   s u b l is t E ( r : Rel E) l l ’ :=

30   f o r a l l e , co un t r l e <= co un t r l ’ e .

31

32   Theorem   t a i l S u bl i s t :

33   f o r a l l E ( r : Rel E) e l l ’ , s u b l is t r ( e : : l ) l ’   −> s u b l i s t r l l ’ .

34   Proof .

35   u nf ol d s u b l i s t .36   i n t r o s .

37   s p e c i a l i z e H   with   e0 .

38   s impl   in   H.

39   d e s t r u ct ( r e 0 e ) .

40   {

41   omega.

42   }

43   {

44   aut o .

45   }46   Qed .

47

48   Fixpoint   remove E ( r : R el E ) l e :=

49   match   l   with

50   | [ ] => [ ]

51   | e ’ : : l ’ =>

52   l e t   l ’ ’ := re mo ve r l ’ e   in

53   i f    r e e ’   then   l ’ ’   e l s e   e ’ : : l ’ ’

54   end .

55

56   Theorem   lengthCountRemove :

57   f o r a l l E ( r : Rel E) l e , l en gt h l = count r l e + le ng th ( remove r l e ) .

58   Proof .

59   i n t r o s .

60   i n d u ct i o n l .

61   {

62   aut o .

63   }

64   {

65   s impl .66   d e s t r u ct ( r e a ) .

67   {

Page 128: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 128/162

Page 129: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 129/162

APÊNDICE C. Demonstrações    128

115   s impl .

116   d e s t r u ct ( r e a ) e qn : E1 .

117   {

118   s p l i t .

119   {120   i n t r o s .

121   d e s t r u ct H .

122   u n fo l d t r a ns   in   H1 .

123   s p e c i a l i z e H1   with   e a e ’ .

124   a s s e r t ( r a e ’ = r e e ’ ) .

125   {

126   aut o .

127   }

128   r e w r i t e H0   in   H2 .

129   un fo ld symm   in   H.130   s p e c i a l i z e H   with   e ’ a .

131   r e w r i t e H2   in   H.

132   r e w r i t e H .

133   d e s t r u c t I H l .

134   aut o .

135   }

136   {

137   d e s t r u c t I H l .

138   aut o .

139   }140   }

141   {

142   s impl .

143   d e s t r u c t ( r e ’ a ) e qn : E2 .

144   {

145   s p l i t .

146   {

147   d e s t r u c t I H l .

148   aut o .

149   }150   {

151   i n t r o s .

152   d e s t r u c t H .

153   u n f ol d t r a ns   in   H1 .

154   s p e c i a l i z e H1   with   e e ’ a .

155   a s s er t ( r e ’ a = r e a ) .

156   {

157   auto .

158   }

159   congruen ce .160   }

161   }

Page 130: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 130/162

Page 131: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 131/162

Page 132: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 132/162

APÊNDICE C. Demonstrações    131

256   {

257   apply removeCount .

258   aut o .

259   aut o .

260   }261   omega.

262   }

263   {

264   a s s e r t ( c ou nt r ( remove r l e ) e0 = co un t r l e0 ) .

265   {

266   apply removeCount .

267   aut o .

268   aut o .

269   }

270   r e w r i t e H10 .271   a s s e r t ( c ou nt r ( remove r l ’ e ) e0 = c oun t r l ’ e0 ) .

272   {

273   apply removeCount .

274   aut o .

275   aut o .

276   }

277   r e w r i t e H11 .

278   u nf ol d s u b l i s t   in  H1’ .

279   s p e c i a l i z e H1 ’   with   e0 .

280   omega.281   }

282   }

283

284   a s s e r t ( l e n gt h ( remove r l e ) <= l e n gt h ( remove r l ’ e ) ) .

285   aut o .

286   omega.

287   }

288   }

289   }

290   Qed .291

292   Theorem   s u b l i s t L e ng t h L e :

293   f o r a l l E ( r : Rel E) l l ’ ,

294   e qu i r   −> s u b l i s t r l l ’   −> l e n g t h l <= l e n g t h l ’ .

295   Proof .

296   i n t r o s .

297   a p p ly s u b l i s tL e n g th L e In d   with   ( n := l e ng t h l ) ( r := r ) .

298   auto .

299   auto .

300   auto .301   Qed .

302

Page 133: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 133/162

Page 134: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 134/162

APÊNDICE C. Demonstrações    133

350   aut o .

351   }

352   Qed .

353

354   Theorem   appCount :355   f o r a l l E ( r : Rel E) l l ’ e ,

356   c ou nt r ( l ++ l ’ ) e = co un t r l e + co un t r l ’ e .

357   Proof .

358   i n d u ct i o n l .

359   {

360   i n t r o s .

361   aut o .

362   }

363   {

364   i n t r o s .365   s p e c i a l i z e I Hl   with   l ’ e .

366   r e w r i t e <−  app_comm_cons .

367   u n f o l d c o un t .

368   f o l d c o un t .

369   d e s t r u ct ( r e a ) .

370   {

371   omega.

372   }

373   {

374   auto .375   }

376   }

377   Qed .

378

379   Theorem   appCountZero :

380   f o r a l l E ( r : Rel E) l l ’ e ,

381   c ou nt r ( l ++ l ’ ) e = 0   −> count r l e = 0 /\ count r l ’ e = 0.

382   Proof .

383   i n t r o s .

384   rew rit e appCount   in   H.385   omega.

386   Qed .

387

388   Definition   c on ta in s E ( r : Rel E) l e :=

389   match   count r l e   with

390   | 0 => f a l s e

391   | _ => true

392   end .

393

394   Theorem   sameContains :395   f o r a l l E ( r : Rel E) l e e ’ ,

396   t r an s r   −> r e e ’ = t r ue   −> c o nt ai ns r l e = c on ta in s r l e ’ .

Page 135: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 135/162

APÊNDICE C. Demonstrações    134

397   Proof .

398   i n t r o s .

399   u n f o l d c o n t a i n s .

400   rew rit e sameCount   with   ( e ’ := e ’ ) .

401   auto .402   auto .

403   auto .

404   Qed .

405

406   Theorem   c o n ta i n s Fa l s eCo u n tZ e r o :

407   f o r a l l E ( r : Rel E) l e ,

408   c on ta in s r l e = f a l s e   −> count r l e = 0 .

409   Proof .

410   i n t r o s .

411   u n fo l d c o n t ai n s   in   H.412   d e st r u ct ( c ou nt r l e ) .

413   {

414   aut o .

415   }

416   {

417   congruen ce .

418   }

419   Qed .

420

421   Theorem   containsTrueCountNotZero :422   f o r a l l E ( r : Rel E) l e ,

423   c on ta in s r l e = t ru e   −> c ou nt r l e <> 0 .

424   Proof .

425   i n t r o s .

426   u n fo l d c o n t ai n s   in   H.

427   d e st r u ct ( c ou nt r l e ) .

428   {

429   congruen ce .

430   }

431   {432   aut o .

433   }

434   Qed .

435

436   Theorem   a pp Co n ta in s Fa l se :

437   f o r a l l E ( r : Rel E) l l ’ e ,

438   t r an s r   −> c o n t ai n s r ( l ++ l ’ ) e = f a l s e   −>

439   c on ta in s r l e = f a l s e / \ c on ta in s r l ’ e = f a l s e .

440   Proof .

441   i n t r o s .442   u n f o l d c o n t a i n s .

443   a p p ly c o n ta i n s Fa l s eCo u n tZ e r o   in   H0 .

Page 136: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 136/162

APÊNDICE C. Demonstrações    135

444   apply appCountZero   in   H0 .

445   d e s t r u c t H0 .

446   r e w r i t e H0 .

447   r e w r i t e H1 .

448   auto .449   Qed .

450   (∗   Outros   ∗)

C.7 LitoralFacts

1   S e t Im p l i c i t A rg um en ts .

2

3   Require Import  Peano_dec .

4

  Require Import   S tr i n g .5

6   Require Import   L i t o r a l .

7   Require Import   S u b l i s t .

8

9   Theorem   s t rE qE q ui : e q u i s t rE q .

10   Proof .

11   u n f o l d e q ui .

12   s p l i t .

13   {

14

  u n fo ld r e f l .15   i n t r o s .

16   u n f o l d s tr Eq .

17   d e s t r u c t ( s t r i ng _ d e c e e ) .

18   {

19   auto .

20   }

21   {

22   congruen ce .

23   }

24

  }25   {

26   s p l i t .

27   {

28   un fo ld symm.

29   i n t r o s .

30   u n f o l d s tr Eq .

31   d e s tr u c t ( s t r i n g _ d e c e e ’ ) .

32   {

33   d e s t r u c t ( s t r i ng _ d e c e ’ e ) .

34

  {35   aut o .

36   }

37   {

Page 137: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 137/162

APÊNDICE C. Demonstrações    136

38   congruen ce .

39   }

40   }

41   {

42   d e s t r u c t ( s t r i ng _ d e c e ’ e ) .43   {

44   congruen ce .

45   }

46   {

47   aut o .

48   }

49   }

50   }

51   {

52   u n f o l d t r a n s .53   i n t r o s .

54   u n f o l d s tr Eq .

55   u n f o l d s t rE q   in   H.

56   d e s t r u c t ( s t r i ng _ d ec e ’ e ) .

57   {

58   r e w r i t e e 0 .

59   aut o .

60   }

61   {

62   d e s tr u c t ( s t r i n g _ d e c e e ’ ) .63   {

64   congruen ce .

65   }

66   {

67   congruen ce .

68   }

69   }

70   }

71   }

72   Qed .73

74   Theorem   natEqEqui : equi natEq .

75   Proof .

76   u n f o l d e q ui .

77   s p l i t .

78   {

79   u n fo ld r e f l .

80   i n t r o s .

81   unfo l d natEq .

82   d e s tr u c t ( eq _n at_d ec e e ) .83   {

84   auto .

Page 138: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 138/162

APÊNDICE C. Demonstrações    137

85   }

86   {

87   congruen ce .

88   }

89   }90   {

91   s p l i t .

92   {

93   un fo ld symm.

94   i n t r o s .

95   unfo ld natEq .

96   des tru ct (eq_nat_dec e e ’ ) .

97   {

98   d e s tr u c t (e q_ na t_ de c e ’ e ) .

99   {100   aut o .

101   }

102   {

103   congruen ce .

104   }

105   }

106   {

107   d e s tr u c t (e q_ na t_ de c e ’ e ) .

108   {

109   congruen ce .110   }

111   {

112   aut o .

113   }

114   }

115   }

116   {

117   u n f o l d t r a n s .

118   i n t r o s .

119   unfo ld natEq .120   unfo ld natEq   in   H.

121   d e s tr u c t ( e q_ na t_ de c e ’ e ) .

122   {

123   r e w r i t e e 0 .

124   aut o .

125   }

126   {

127   des tru ct ( eq_nat_dec e e ’ ) .

128   {

129   congruen ce .130   }

131   {

Page 139: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 139/162

APÊNDICE C. Demonstrações    138

132   congruen ce .

133   }

134   }

135   }

136   }137   Qed .

138

139   Theorem   c la s s Eq E q ui : e q u i c l a s s E q .

140   Proof .

141   u n f o l d e q ui .

142   s p l i t .

143   {

144   u n fo ld r e f l .

145   i n t r o s .

146   u n f o l d c l a s s Eq .147   d e s t r u c t e .

148   p o s e p r o o f s tr Eq Eq ui .

149   u n f ol d e q ui   in   H.

150   d e s t r u c t H .

151   u nf ol d r e f l   in   H.

152   s p e c i a l i z e H   with   s .

153   aut o .

154   }

155   {

156   s p l i t .157   {

158   un fo ld symm.

159   i n t r o s .

160   u n f o l d c l a s s E q .

161   d e s t r u c t e .

162   d e s t r u c t e ’ .

163   p o s e p r o o f s tr Eq Eq ui .

164   u n f o l d e q u i   in   H.

165   d e s t r u c t H .

166   d e s t r u c t H0 .167   un fo ld symm   in   H0 .

168   s p e c i a l i z e H0   with   s s 0 .

169   auto .

170   }

171   {

172   u n f o l d t r a n s .

173   i n t r o .

174   i n t r o .

175   i n t r o .

176   u n f o l d c l a s s E q .177   d e s t r u c t e .

178   d e s t r u c t e ’ .

Page 140: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 140/162

APÊNDICE C. Demonstrações    139

179   d e s t r u ct e ’ ’ .

180   p o s e p r o o f s tr Eq Eq ui .

181   u n f o l d e q u i   in   H.

182   d e s t r u c t H .

183   d e s t r u c t H0 .184   u n fo l d t r a ns   in   H1 .

185   s p e c i a l i z e H1   with   s s 0 s 1 .

186   auto .

187   }

188   }

189   Qed .

190

191   Theorem   pathEqEqui : equi pathEq .

192   Proof .

193   u n f o l d e q ui .194   s p l i t .

195   {

196   u n fo ld r e f l .

197   i n t r o s .

198   unf old pathEq .

199   d e s t r u c t e .

200   pose proof natEqEqui .

201   u n f ol d e q ui   in   H.

202   d e s t r u c t H .

203   u nf ol d r e f l   in   H.204   s p e c i a l i z e H   with   n .

205   aut o .

206   }

207   {

208   s p l i t .

209   {

210   un fo ld symm.

211   i n t r o s .

212   unf old pathEq .

213   d e s t r u c t e .214   d e s t r u c t e ’ .

215   pose proof natEqEqui .

216   u n f o l d e q u i   in   H.

217   d e s t r u c t H .

218   d e s t r u c t H0 .

219   un fo ld symm   in   H0 .

220   s p e c i a l i z e H0   with   n n0 .

221   auto .

222   }

223   {224   u n f o l d t r a n s .

225   i n t r o .

Page 141: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 141/162

APÊNDICE C. Demonstrações    140

226   i n t r o .

227   i n t r o .

228   unf old pathEq .

229   d e s t r u c t e .

230   d e s t r u c t e ’ .231   d e s t r u ct e ’ ’ .

232   pose proof natEqEqui .

233   u n f o l d e q u i   in   H.

234   d e s t r u c t H .

235   d e s t r u c t H0 .

236   u n fo l d t r a ns   in   H1 .

237   s p e c i a l i z e H1   with   n n0 n1 .

238   auto .

239   }

240   }241   Qed .

242

243   Theorem   c l as s Path Eq Eq u i : e q u i c l a s sPa th Eq .

244   Proof .

245   u n f o l d e q ui .

246   s p l i t .

247   {

248   u n fo ld r e f l .

249   i n t r o s .

250   u n f o l d c l a s sPa th Eq .251   d e s t r u c t e .

252   p o s e p r o o f c l a s s Eq Equ i .

253   u n f ol d e q ui   in   H.

254   d e s t r u c t H .

255   u nf ol d r e f l   in   H.

256   s p e c i a l i z e H   with   c .

257   r e w r i t e H .

258   pose proof pathEqEqui .

259   u n f ol d e q ui   in   H1 .

260   d e s t r u c t H1 .261   u nf ol d r e f l   in   H1 .

262   s p e c i a l i z e H1   with   p .

263   aut o .

264   }

265   {

266   s p l i t .

267   {

268   un fo ld symm.

269   i n t r o s .

270   u n f o l d c l a ss Pa th Eq .271   d e s t r u c t e .

272   d e s t r u c t e ’ .

Page 142: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 142/162

APÊNDICE C. Demonstrações    141

273   p o s e p r o o f c l a s s Eq Equ i .

274   u n f o l d e q u i   in   H.

275   d e s t r u c t H .

276   d e s t r u c t H0 .

277   un fo ld symm   in   H0 .278   s p e c i a l i z e H0   with   c c 0 .

279   r e w r i t e H0 .

280   pose proof pathEqEqui .

281   u n f o l d e q u i   in   H2 .

282   d e s t r u c t H2 .

283   d e s t r u c t H3 .

284   un fo ld symm   in   H3 .

285   s p e c i a l i z e H3   with   p p0 .

286   r e w r i t e H3 .

287   auto .288   }

289   {

290   u n f o l d t r a n s .

291   i n t r o s .

292   u n f o l d c l a ss Pa th Eq .

293   d e s t r u c t e .

294   d e s t r u c t e ’ .

295   d e s t r u ct e ’ ’ .

296   u n f o l d c l a ss Pa th Eq   in   H.

297   d e s t r u c t ( c l a s s E q c c 0 ) eq n : E1 .298   {

299   d e s tr u c t (p athEq p p0 ) e qn : E2 .

300   {

301   p o s e p r o o f c l a s s Eq Eq u i .

302   u n f o l d e q u i   in   H0 .

303   d e s t r u c t H0 .

304   d e s t r u c t H1 .

305   u n f ol d t r a ns   in   H2 .

306   a s s e r t ( c l as s Eq c 0 c 1 = c l as s E q c c 1 ) .

307   {308   auto .

309   }

310   r e w r i t e H3 .

311   pose proof pathEqEqui .

312   u n f o l d e q u i   in   H4 .

313   d e s t r u c t H4 .

314   d e s t r u c t H5 .

315   u n f ol d t r a ns   in   H6 .

316   a s s e r t ( p athEq p 0 p1 = p athEq p p1 ) .

317   {318   auto .

319   }

Page 143: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 143/162

APÊNDICE C. Demonstrações    142

320   r e w r i t e H7 .

321   aut o .

322   }

323   {

324   congruen ce .325   }

326   }

327   {

328   congruen ce .

329   }

330   }

331   }

332   Qed .

333

334   Theorem   o bj Eq Eq ui : e q u i o bj Eq .335   Proof .

336   u n f o l d e q ui .

337   s p l i t .

338   {

339   u n fo ld r e f l .

340   i n t r o s .

341   unfo l d objEq .

342   d e s t r u c t e .

343   p o s e p r o o f s tr Eq Eq ui .

344   u n f ol d e q ui   in   H.345   d e s t r u c t H .

346   u nf ol d r e f l   in   H.

347   s p e c i a l i z e H   with   s .

348   aut o .

349   }

350   {

351   s p l i t .

352   {

353   un fo ld symm.

354   i n t r o s .355   unfo ld objEq .

356   d e s t r u c t e .

357   d e s t r u c t e ’ .

358   p o s e p r o o f s tr Eq Eq ui .

359   u n f o l d e q u i   in   H.

360   d e s t r u c t H .

361   d e s t r u c t H0 .

362   un fo ld symm   in   H0 .

363   s p e c i a l i z e H0   with   s s 0 .

364   auto .365   }

366   {

Page 144: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 144/162

APÊNDICE C. Demonstrações    143

367   u n f o l d t r a n s .

368   i n t r o .

369   i n t r o .

370   i n t r o .

371   unfo ld objEq .372   d e s t r u c t e .

373   d e s t r u c t e ’ .

374   d e s t r u ct e ’ ’ .

375   p o s e p r o o f s tr Eq Eq ui .

376   u n f o l d e q u i   in   H.

377   d e s t r u c t H .

378   d e s t r u c t H0 .

379   u n fo l d t r a ns   in   H1 .

380   s p e c i a l i z e H1   with   s s 0 s 1 .

381   auto .382   }

383   }

384   Qed .

C.8 AnalyzeSpecFacts

1   S e t Im p l i c i t A rg um en ts .

2

3

  Require Import   L i s t .   Import   L i s tN o ta t i o n s .4

5   Require Import   Lim.

6   Require Import   L i t o r a l .

7   Require Import   L i t o r a l F a c t s .

8   Require Import   ListOptionSeq .

9   Require Import   ListS eq .

10   Require Import  Seq .

11   Require Import   S u b l i s t .

12

13

  Definition   a na ly ze Sp ec S c l a s s e s c l a s s s pe c n : =14   l e t   ( s , _) := a na ly ze Sp ec c l a s s e s c l a s s s pe c n   in   s .

15

16   Theorem   analyzeSpecS_t1 :

17   f o r a l l c l a ss e s c l a s s spec ,

18   n on De cL i st Se q ( a n al y ze S pe c S c l a s s e s c l a s s s p e c )

19   /\ s u b l i s tB n d L is t S eq ( a na ly ze Sp ec S c l a s s e s c l a s s s p ec ) .

20   Proof .

21   i n t r o s .

22   s p l i t .

23

  {24   unfo l d nonDecListSeq .

25   i n t r o s .

26   u n f ol d s u f f E q L i s t .

Page 145: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 145/162

Page 146: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 146/162

APÊNDICE C. Demonstrações    145

74   {

75   e x i s t s [ ] .

76   auto .

77   }

78   }79   {

80   u n f o l d s u b l i s t B n d L i s t S e q .

81   e x i s t s c l as s Pa t hE q .

82   u n f o l d a n a l y ze S p e cS .

83   u n f o l d a n a l y z e Sp e c .

84   d e s tr u c t ( i n d e xS p e c s pe c ) .

85   e x i s t s ( l i st _ pr o d c l a s s e s l ) .

86   s p l i t .

87   {

88   apply c lassPathEqEqui .89   }

90   {

91   u nf ol d s u b l i s t .

92   d e s tr u ct p .

93   d e s t r u ct s .

94   d e s t r u c t ( a n al y ze T ra v s l 0 ) .

95   {

96   i n d u c t i o n n 0 .

97   {

98   i n t r o s .99   u n f o l d a n a l y z e Cl a s s Pa th s .

100   s impl .

101   omega.

102   }

103   {

104   u n f o l d a n a l y z e Cl a s s Pa th s .

105   f o l d a n a l y ze C l a ss P a t h s .

106   d e s tr u c t ( a na ly ze C la ss Pa th s c l a s s e s l l 0 [ ] [ ( c l a ss , p ) ] n 0 ) .

107   d e s t r u c t o .

108   {109   d e s t r u ct l 2 .

110   {

111   aut o .

112   }

113   {

114   d e s t r u c t ( c o n t a in s C l a ss P a t h l 1 p0 ) e qn : E1 .

115   {

116   auto .

117   }

118   {119   d e s t r u c t ( c o n t a in s C l a ss P a t h ( l i s t _ p r o d c l a s s e s l ) p0 ) e qn : E2 .

120   {

Page 147: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 147/162

APÊNDICE C. Demonstrações    146

121   i n t r o s .

122   a s se r t (

123   c ou nt c l as s Pa t hE q ( p 0 : : l 1 ) e <=

124   c ou nt c la ss Pa th Eq ( l i s t _p r o d c l a s s e s l ) e

125   ) .126   {

127   s impl .

128   d e s t r u c t ( c l as s Pa t hE q e p0 ) e qn : E3 .

129   {

130   u n f o l d c o n t ai n s C l a ss P a t h   in   E1 .

131   u n f o l d c o u ntCl a s sPa th   in   E1 .

132   d e s t r u c t ( c o u nt c l as s Pa t hE q l 1 p0 ) eq n : E4 .

133   {

134   p o s e p r o o f c l a ss Pa thEq Equ i .

135   u n f ol d e q ui   in   H.136   d e s t r u c t H .

137   d e s t r u c t H0 .

138   a s se r t (

139   c ou nt c l as s Pa t hE q l 1 e =

140   c ou nt c l as s Pa t hE q l 1 p0

141   ) .

142   {

143   apply sameCount .

144   auto .

145   auto .146   }

147   r e w r i t e H2 .

148   r e w r i t e E4 .

149   a s se r t (

150   c ou nt c la ss Pa th Eq ( l i s t _p r o d c l a s s e s l ) e =

151   c ou nt c l as s Pa t hE q ( l i s t _ p r o d c l a s s e s l ) p0

152   ) .

153   {

154   apply sameCount .

155   auto .156   auto .

157   }

158   r e w r i t e H3 .

159   u n f o l d c o n t a in s C l a ss P a t h   in   E2 .

160   u n f ol d c o n t ai n s   in   E2 .

161   d e s t r u c t ( c o u nt c l as s Pa t hE q

162   ( l i s t _p r o d c l a s s e s l ) p0 ) eqn : E5 .

163   {

164   congruenc e .

165   }166   {

167   omega.

Page 148: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 148/162

Page 149: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 149/162

APÊNDICE C. Demonstrações    148

215   f o r a l l c l a ss e s c l a s s spec ,

216   c on vS eq ( a n al y ze S pe c S c l a s s e s c l a s s s p e c ) .

217   Proof .

218   i n t r o s .

219   p o s e p r o o f a n a ly z eS p ec S _t1 .220   s p e c i a l i z e H   with   c l a s s e s c l a s s s pe c .

221   d e s t r u c t H .

222   apply nonDecSublistBndListSeqConv .

223   auto .

224   auto .

225   Qed .

226

227   Theorem   consNotEqual :

228   f o r a l l E ( l : l i s t E) ( e : E ) , l <> e : : l .

229   Proof .230   i n t r o s .

231   i n d u ct i o n l .

232   {

233   d i s c r i m i n a t e .

234   }

235   {

236   i n j e c t i o n .

237   i n t r o s .

238   d e s t r u c t I H l .

239   r e w r i t e <−   H1 .240   aut o .

241   }

242   Qed .

243

244   Definition   an al yz eS pe cT c l a s s e s c l a s s s pe c n :=

245   l e t   ( _, t ) := a na ly ze Sp ec c l a s s e s c l a s s s pe c n   in   t .

246

247   Theorem   analyzeSpecT_t1 :

248   f o r a l l c l a ss e s c l a s s spec ,

249   e x i s t s N,250   d e cL i s tO p t io n Se q ( s u f f S e q ( a na ly ze Sp ec T c l a s s e s c l a s s s p e c ) N ) .

251   Proof .

252   i n t r o s .

253

254   p o s e p r o o f a n a ly z eS p ec S _t2 .

255   s p e c i a l i z e H   with   c l a s s e s c l a s s s pe c .

256   u n f o l d c on vS eq   in   H.

257   d e s t r u ct H a s [ N ] .

258   e x i s t s N.

259

260   u n f o l d d e c L i s tO p t i o n Se q .

261   u n f o l d s u f f L i s t O p t i o n .

Page 150: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 150/162

APÊNDICE C. Demonstrações    149

262   u n f o l d s u f f S e q .

263   unfo ld analyzeSpecT .

264   u n f o l d a n a l y z e S p e c .

265   u n f o l d c o ns S e q   in   H.

266   u n fo l d s u f f S e q   in   H.267   u n f o l d a n a l y ze S p e cS   in   H.

268   u n f o l d a n a l y z e Sp e c   in   H.

269

270   i n t r o s .

271   a s s e r t (N + ( S n ) = S (N + n ) ) .

272   {

273   omega.

274   }

275   r e w r i t e H0 .

276   s p e c i a l i z e H   with   n .277   r e w r i t e H0   in   H.

278

279   u n f o l d a n a l y z e Cl a s s Pa th s .

280   f o l d a n a l yz e C l as s P a t hs .

281   u n f o l d a n a l yz e C l as s P a t hs   in   H.

282   f o l d a n a l yz e C l as s P a t hs   in   H.

283

284   d e s t r u c t ( i n de x Sp e c s p e c ) .

285   d e st r u ct p .

286   d e s t r u ct s .287   d e s t r u c t ( a n al y ze T ra v s l 0 ) .

288   {

289   d e st r u ct ( a na ly ze Cl as sP at hs c l a s s e s l l 0 [ ] [ ( c l a ss , p ) ] (N + n ) ) .

290   d e s t r u c t o .

291   {

292   d e s t r u ct l 2 .

293   {

294   aut o .

295   }

296   {297   d e s t r u c t ( c o n t a in s C l a s sP a t h l 1 p0 ) .

298   {

299   e x i s t s l 2 .

300   e x i s t s p0 .

301   aut o .

302   }

303   {

304   d e s t r u c t ( c o nt a in s Cl a ss P at h ( l i s t _p r o d c l a s s e s l ) ) .

305   {

306   d e s t r u c t p0 .307   d e s t r u ct ( a na ly ze Pa th c l a s s e s l 0 c p0 ) .

308   {

Page 151: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 151/162

APÊNDICE C. Demonstrações    150

309   apply consNotEqual   in   H.

310   c o n t r a d i c t i o n .

311   }

312   {

313   apply consNotEqual   in   H.314   c o n t r a d i c t i o n .

315   }

316   }

317   {

318   e x i s t s l 2 .

319   e x i s t s p0 .

320   auto .

321   }

322   }

323   }324   }

325   {

326   auto .

327   }

328   }

329   {

330   aut o .

331   }

332   Qed .

333

334   Theorem   analyzeSpecTLim :

335   f o r a l l c l a ss e s c l a s s spec ,

336   l i m ( a n al yz eS pe cT c l a s s e s c l a s s s p e c ) None \/

337   l i m ( a na ly ze Sp ec T c l a s s e s c l a s s s p e c ) ( Some [ ] ) .

338   Proof .

339   i n t r o s .

340   pose p roof analyzeSpecT_t1 .

341   s p e c i a l i z e H   with   c l a s s e s c l a s s s pe c .

342   apply hasDecOptionListSuffSeqLim .

343   auto .344   Qed .

345

346   Theorem   analyzeSpecLim :

347   f o r a l l c l a ss e s c l a s s spec ,

348   e x i s t s N,

349   f o r a l l n ,

350   l e t   ( _, t ) := a n al y ze Sp e c c l a s s e s c l a s s s p ec (N + n )   in

351   t = None \/ t = Some [ ] .

352   Proof .

353   i n t r o s .354   pose proof analyzeSpecTLim .

355   s p e c i a l i z e H   with   c l a s s e s c l a s s s pe c .

Page 152: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 152/162

APÊNDICE C. Demonstrações    151

356   u n fo l d l im   in   H.

357   u n fo l d s u f f S e q   in   H.

358   unfo ld analyzeSpecT   in   H.

359   d e s t r u c t H .

360   {361   d e s t r u ct H a s [N ] .

362   e x i s t s N.

363   i n t r o s .

364   s p e c i a l i z e H   with   n .

365   d e s t r u ct ( a na l yz eS p ec c l a s s e s c l a s s s p ec (N + n ) ) .

366   aut o .

367   }

368   {

369   d e s t r u ct H a s [N ] .

370   e x i s t s N.371   i n t r o s .

372   s p e c i a l i z e H   with   n .

373   d e s t r u ct ( a na l yz eS p ec c l a s s e s c l a s s s p ec (N + n ) ) .

374   aut o .

375   }

376   Qed .

C.9 InterpretSpecFacts

1   S e t Im p l i c i t A rg um en ts .

2

3   Require Import   L i s t .   Import   L i s tN o ta t i o n s .

4

5   Require Import   Lim.

6   Require Import   L i t o r a l .

7   Require Import   L i t o r a l F a c t s .

8   Require Import   ListOptionSeq .

9   Require Import   ListS eq .

10

  Require Import  Seq .11   Require Import   S u b l i s t .

12

13   Definition   f i l t e r 2 S ( p a ths : l i s t PATH) ( a l l O b j s : l i s t OBJ ) ( s : l i s t OBJ )

14   ( obj s : l i s t OBJ) ( path : PATH) :=

15   l e t   ( s , _) := f i l t e r 2 p a th s a l l O b j s s o b j s p at h   in   s .

16

17   Definition   f i l t er 2R ( paths : l i s t PATH) ( a l l Obj s : l i s t OBJ) ( s : l i s t OBJ)

18   ( obj s : l i s t OBJ) ( path : PATH) :=

19   l e t   (_ , r ) := f i l t e r 2 p a th s a l l O b j s s o b j s p at h   in   r .

20

21   Theorem   f i l t e r 2_ t 1 :

22   f o r a l l p at hs a l l O b j s ( s : l i s t OBJ) o b j s pat h ,

23   e x i s t s ( s ’ : l i s t OBJ ) ,

Page 153: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 153/162

APÊNDICE C. Demonstrações    152

24   f i l t e r 2 S p at hs a l l O b js s o b js p at h = s ’ ++ s

25   /\ ( f o r a l l ob j ,

26   c ou nt o bj Eq s ’ o b j = 0 \ /

27   c ou nt o bj Eq s ’ o b j = 1 / \

28   c o n t ai n s ob jE q a l l O b j s o bj = t r u e /\29   c o n t ai n s ob jE q s o b j = f a l s e )

30   /\ l e n g th s ’ = l e ng t h ( f i l t e r 2 R p at hs a l l O b j s s o b j s p at h ) .

31   Proof .

32   i n t r o s .

33   i n d u c t i o n o b j s .

34   {

35   e x i s t s [ ] .

36   aut o .

37   }

38   {39   u n fo ld f i l t e r 2 S .

40   u n f ol d f i l t e r 2 R .

41   un fo ld f i l t e r 2 .

42   fo ld f i l t e r 2 .

43   d e s t r u c t I H ob j s .

44   u nf ol d f i l t e r 2 S   in   H.

45   u n fo ld f i l t e r 2 R   in   H.

46   d e s t r u c t ( f i l t e r 2 p a th s a l l O b j s s o b j s p at h ) .

47   d e s t r u c t ( c o nt a i ns O b j a l l O b j s a ) e qn : E1 .

48   {49   d e s t r u c t ( c o n ta i n sO b j l a ) eq n : E2 .

50   {

51   e x i st s x .

52   aut o .

53   }

54   {

55   d e s t r u ct H .

56   d e s t r u c t H0 .

57   r e w r i t e H .

58   e x i s t s ( a : : x ) .59   s p l i t .

60   {

61   aut o .

62   }

63   {

64   s p l i t .

65   {

66   s impl .

67   i n t r o s .

68   d e s t r u c t ( o bj Eq o b j a ) e qn : E3 .69   {

70   r i g h t .

Page 154: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 154/162

Page 155: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 155/162

APÊNDICE C. Demonstrações    154

118   }

119   {

120   aut o .

121   }

122   }123   {

124   s impl .

125   omega.

126   }

127   }

128   }

129   }

130   {

131   e x i st s x .

132   auto .133   }

134   }

135   Qed .

136

137   Definition   i n t e rp r e t Sp e c 2 S s p ec a l l O b j s o b j s n :=

138   l e t   ’ ( _, s , _) := i n t e r p r et S p e c 2 s pe c a l l O b j s o b j s n   in   s .

139

140   Theorem   i n t e rp r e t Sp e c 2 S_ t 1 :

141   f o r a l l s pe c a ll O b js o bj s ,

142   n on De cL i st Se q ( i n t e r p r e t S p e c 2 S s p e c a l l O b j s o b j s )143   /\ s u b l i s t Bn d L i st S e q ( i n t e rp r e t Sp e c 2S s pe c a l l O b j s o b j s ) .

144   Proof .

145   i n t r o s .

146   s p l i t .

147   {

148   unfo l d nonDecListSeq .

149   u n f o l d i n t e r p r e t S p e c 2 S .

150   u n f o l d i n t e r p r e t S p e c 2 .

151   u n f o l d i n t e r p r e t S p e c .

152   u n f o l d i n t e r p r e t Ob j s P a t h s .153   f o l d i n t e r p r e t Ob j s P a t h s .

154   d e s tr u c t ( i n d e xS p e c s pe c ) .

155   d e st r u ct p .

156   d e s t r u ct s .

157   i n t r o s .

158   d e s t r u ct ( i n t er p r et O b js P a t hs f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o bj s , p ) ] n0 ) .

159   d e s t r u c t p0 .

160   d e s t r u c t o .

161   {

162   d e s t r u ct l 3 .163   {

164   e x i s t s [ ] .

Page 156: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 156/162

APÊNDICE C. Demonstrações    155

165   aut o .

166   }

167   {

168   d e s t r u c t p0 .

169   d e s t r u c t ( f i l t e r 2 l a l l O b j s l 2 l 4 p0 ) eq n : E1 .170   p os e p r o of f i l t e r 2 _ t 1 .

171   s p e c i a l i z e H   with   l a l l O bj s l 2 l 4 p0 .

172   d e s t r u ct H .

173   d e s t r u ct H .

174   u nf ol d f i l t e r 2 S   in   H.

175   r e w r i t e E1   in   H.

176   d e s t r u ct ( i n t e rp r e t Pa t h l 0 al l O b j s l 6 p0 ) .

177   {

178   e x i st s x .

179   aut o .180   }

181   {

182   e x i st s x .

183   aut o .

184   }

185   }

186   }

187   {

188   e x i s t s [ ] .

189   auto .190   }

191   }

192   {

193   u n f o l d s u b l i s t B n d L i s t S e q .

194   e x i s t s o bj Eq .

195   e x i s t s a l l Ob j s .

196   s p l i t .

197   {

198   apply objEqEqui .

199   }200   {

201   i n d uc t i o n n .

202   {

203   u nf ol d s u b l i s t .

204   u n f o l d i n t e r p r e t S p e c 2 S .

205   u n f o l d i n t e r p r e t S p e c 2 .

206   u n f o l d i n t e r p r e t S p e c .

207   d e s tr u c t ( i n d e xS p e c s p e c ) .

208   d e st r u ct p .

209   d e s t r u ct s .210   u n f o l d i n t e r p r e t Ob j s P a t h s .

211   s impl .

Page 157: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 157/162

APÊNDICE C. Demonstrações    156

212   i n t r o s .

213   omega.

214   }

215   {

216   u n f o l d i n t e r p r e t S p e c 2 S   in   IHn.217   u n fo l d i n t e r p re t S p e c 2   in   IHn.

218   u n fo l d i n t e r p r e t Sp e c   in   IHn.

219   u n f o l d i n t e r p r e t S p e c 2 S .

220   u n f o l d i n t e r p r e t S p e c 2 .

221   u n f o l d i n t e r p r e t S p e c .

222   d e s tr u c t ( i n d e xS p e c s p e c ) .

223   d e st r u ct p .

224   d e s t r u ct s .

225   u n f o l d i n t e r p r e t Ob j s P a t h s .

226   f o l d i n t e r p r e t O bj s P a t h s .227   d e s t r u ct ( i n t er p r et O b js P a t hs f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o bj s , p ) ] n ) .

228   d e s t r u c t p0 .

229   d e s t r u c t o .

230   d e s t r u ct l 3 .

231   {

232   aut o .

233   }

234   {

235   d e s t r u c t p0 .

236   d e s t r u c t ( f i l t e r 2 l a l l O b j s l 2 l 4 p0 ) e qn : E1 .237   p os e p r oo f f i l t e r 2 _ t 1 .

238   s p e c i a l i z e H   with   l a l lO b js l 2 l 4 p0 .

239   d e s t r u c t H .

240   d e s t r u c t H .

241   u nf ol d f i l t e r 2 S   in   H.

242   r e w r i t e E1   in   H.

243   a s s e r t ( s u b l i s t objEq l 5 a l l Ob j s ) .

244   {

245   u nf ol d s u b l i s t   in   IHn.

246   u nf ol d s u b l i s t .247   i n t r o s .

248   s p e c i a l i z e IHn   with   e .

249   r e w r i t e H .

250   re wr it e appCount .

251   d e s t r u c t H0 .

252   s p e c i a l i z e H0   with   e .

253   d e s t r u c t H0 .

254   {

255   omega.

256   }257   {

258   d e s t r u c t H0 .

Page 158: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 158/162

APÊNDICE C. Demonstrações    157

259   d e s t r u c t H1 .

260   d e s t r u c t H2 .

261   apply containsTrueCountNotZero   in   H1 .

262   a p p ly c o n ta i n s Fa l se Co u n tZ e r o   in   H2 .

263   omega.264   }

265   }

266   d e s t r u c t ( i n t e rp r e t Pa t h l 0 a l l O b j s l 6 p0 ) .

267   {

268   d e s t r u ct l 6 .

269   {

270   aut o .

271   }

272   {

273   aut o .274   }

275   }

276   {

277   d e s t r u ct l 6 .

278   {

279   aut o .

280   }

281   {

282   aut o .

283   }284   }

285   }

286   {

287   aut o .

288   }

289   }

290   }

291   }

292   Qed .

293

294   Theorem   i n t e rp r e t Sp e c 2 S_ t 2 :

295   f o r a l l s pe c a ll O b js o bj s ,

296   c on vS eq ( i n t e r p r e t S p e c 2 S s p e c a l l O b j s o b j s ) .

297   Proof .

298   i n t r o s .

299   p o s e p r o o f i n te r p r e tS p e c 2 S _ t1 .

300   s p e c i a l i z e H   with   s p e c a l l O b j s o b j s .

301   d e s t r u c t H .

302   apply nonDecSublistBndListSeqConv .

303   auto .304   auto .

305   Qed .

Page 159: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 159/162

APÊNDICE C. Demonstrações    158

306

307   Definition   i n t er p re t S pe c 2T s p ec a l l O b j s o b j s n : =

308   l e t   ’ (_, _, t ) := i n t er p re t S pe c 2 s pe c a l l Ob j s o b js n   in   t .

309

310   Theorem   i nte r p r e tSp e c 2 T_ t1 :311   f o r a l l s pe c a ll O b js o bj s ,

312   e x i s t s N,

313   d e cL i s tO p t io n Se q ( s u f f S e q ( i n t e r pr e t S p ec 2 T s p e c a l l O b j s o b j s ) N ) .

314   Proof .

315   i n t r o s .

316

317   p o s e p r o o f i n te r p r e tS p e c 2 S _ t2 .

318   s p e c i a l i z e H   with   s p e c a l l O b j s o b j s .

319   d e s t r u ct H a s [ N ] .

320   e x i s t s N.321

322   u n f o l d d e c L i s tO p t i o n Se q .

323   u n f o l d s u f f L i s t O p t i o n .

324   u n f o l d s u f f S e q .

325   u n f o l d i n te r p r e tS p e c 2 T .

326   u n f o l d i n t e r p r e t S p e c 2 .

327   u n f o l d i n t e r p r e t S p e c .

328   u n f o l d c o ns S e q   in   H.

329   u n fo l d s u f f S e q   in   H.

330   u n f o l d i n t e r p r e t S p e c 2 S   in   H.331   u n fo l d i n t e r p r et S p e c 2   in   H.

332   u n fo l d i n t e r p r e t S pe c   in   H.

333

334   i n t r o s .

335   a s s e r t (N + ( S n ) = S (N + n ) ) .

336   {

337   omega.

338   }

339   r e w r i t e H0 .

340   s p e c i a l i z e H   with   n .341   r e w r i t e H0   in   H.

342

343   u n f o l d i n t e r p r e t Ob j s P a t h s .

344   f o l d i n t e r p r e t Ob j s P a t h s .

345   u n f o l d i n t e r p r e t Ob j s P a t h s   in   H.

346   f o l d i n t e r p r e t Ob j s P a t h s   in   H.

347

348   d e s t r u c t ( i n de x Sp e c s p e c ) .

349   d e st r u ct p .

350   d e s t r u ct s .351   d e s t r u ct ( i n t er p r et O b js P a t hs f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o bj s , p ) ] (N + n ) ) .

352   d e s t r u c t p 0 .

Page 160: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 160/162

APÊNDICE C. Demonstrações    159

353   d e s t r u c t o .

354   {

355   d e s t r u ct l 3 .

356   {

357   auto .358   }

359   {

360   d e s t r u c t p0 .

361

362   p os e p r oo f f i l t e r 2 _ t 1 .

363   s p e c i a l i z e H1   with   l a l lO bj s l 2 l 4 p0 .

364   u nf ol d f i l t e r 2 S   in   H1 .

365   u nf ol d f i l t e r 2 R   in   H1 .

366   d e s t r u c t H1 .

367   d e s t r u c t H1 .368   d e s t r u c t H2 .

369

370   d e s t r u c t ( f i l t e r 2 l a l l O b j s l 2 l 4 p0 ) e qn : E1 .

371   d e s t r u ct ( i n t e rp r e t P at h l 0 a l l O b j s l 6 p0 ) eqn : E2 .

372   {

373   a s s e r t ( l 5 = [ ] ++ l 5 ) .

374   {

375   aut o .

376   }

377   r e w r i t e H4   in   H1 .378   r e w r i t e H   in   H1 .

379   apply app_inv_tai l   in   H1 .

380   r e w r i t e <−   H1   in   H3 .

381   s impl   in   H3 .

382   symmetry   in   H3 .

383   apply lengthZeroEmptyList   in   H3 .

384   r e w r i t e H3   in   E2 .

385   u n f o l d i n t e r p r e t P a t h   in   E2 .

386   i n j e c t i o n E2 .

387   i n t r o s .388   r e w r i t e <−   H5 .

389   rew rit e app_nil_r .

390   e x i s t s l 3 .

391   e x i s t s ( l 4 , p0 ) .

392   aut o .

393   }

394   {

395   a s s e r t ( l 5 = [ ] ++ l 5 ) .

396   {

397   aut o .398   }

399   r e w r i t e H4   in   H1 .

Page 161: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 161/162

APÊNDICE C. Demonstrações    160

400   r e w r i t e H   in   H1 .

401   apply app_inv_tai l   in   H1 .

402   r e w r i t e <−   H1   in   H3 .

403   s impl   in   H3 .

404   symmetry   in   H3 .405   apply lengthZeroEmptyList   in   H3 .

406   r e w r i t e H3   in   E2 .

407   u n f o l d i n t e r p r e t P a t h   in   E2 .

408   congruen ce .

409   }

410   }

411   }

412   {

413   aut o .

414   }415   Qed .

416

417   Theorem   i nte r p r e tSp e c 2 T_ t2 :

418   f o r a l l s pe c a ll O b js o bj s ,

419   l i m ( i n t e r pr e t S p ec 2 T s p ec a l l O b j s o b j s ) None \/

420   l i m ( i n te r p r e tS p e c 2 T s p e c a l l O b j s o b j s ) (Some [ ] ) .

421   Proof .

422   i n t r o s .

423   p o s e p r o o f i n te r p r e tS p e c2 T_ t1 .

424   s p e c i a l i z e H   with   s p e c a l l O b j s o b j s .425   apply hasDecOptionListSuffSeqLim .

426   auto .

427   Qed .

428

429   Theorem   i n t e rp r e t Sp e c 2 Li m :

430   f o r a l l s pe c a ll O b js o bj s ,

431   e x i s t s N,

432   f o r a l l n ,

433   l e t   ’ (_, _, t ) := i n t e r p re t S p e c 2 s p ec a l l O b j s o b j s (N + n )   in

434   t = None \/ t = Some [ ] .435   Proof .

436   i n t r o s .

437   p o s e p r o o f i n te r p r e tS p e c2 T_ t2 .

438   s p e c i a l i z e H   with   s p e c a l l O b j s o b j s .

439   u n fo l d l im   in   H.

440   u n fo l d s u f f S e q   in   H.

441   u n f o l d i n t e r pr e t S p ec 2 T   in   H.

442   d e s t r u c t H .

443   {

444   d e s t r u ct H a s [N ] .445   e x i s t s N.

446   i n t r o s .

Page 162: Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 162/162

APÊNDICE C. Demonstrações    161

447   s p e c i a l i z e H   with   n .

448   d e s t r u ct ( i n t e r p re t S p e c 2 s p e c a l l O b j s o b j s ( N + n ) ) .

449   d e st r u ct p .

450   aut o .

451   }452   {

453   d e s t r u ct H a s [N ] .

454   e x i s t s N.

455   i n t r o s .

456   s p e c i a l i z e H   with   n .

457   d e s t r u ct ( i n t e r p re t S p e c 2 s p e c a l l O b j s o b j s ( N + n ) ) .

458   d e st r u ct p .

459   aut o .

460   }

461   Qed .