Como exemplo de um serviço de controlo, apresenta-se aqui o desenho de um vocacio- nado para a depuração. Este serviço baseia-se em trabalho antes desenvolvido com base no primeiro protótipo da DAMS, para a depuração de aplicações paralelas e distribuídas. Este foi usado para ensaiar a necessidade de uma infraestrutura geral que permitisse desenvol- ver outras aplicações com base num conjunto de funcionalidades comuns aos depuradores sequenciais. Seria assim mais fácil a construção de novas ferramentas que tivessem neces- sidade de aceder aos processos da aplicação distribuída, p.e. para observar o seu estado (dados, fluxo de execução, etc.) ou controlar a sua execução (ordem de execução entre os vários processos, p.e.).
Nesse sentido foi desenvolvido um sistema dedicado a essa infraestrutura para depuração (DDBG [25, 35]), e outro semelhante (o PDBG[81, 35]), mas em que este último utiliza como base a primeira versão do sistema DAMS. As soluções desenvolvidas nesse projecto permitiram verificar, para o segundo caso, a vantagem de se dispor de uma infraestrutura de base, sobre o qual as várias ferramentas foram na altura desenvolvidas [34, 22, 23].
Partindo dessa experiência, veja-se como se pode dispor que um serviço semelhante a ser agora suportado pela nova DAMS, continuando a permitir assim a integração deste tipo de operações na DAMS. Nesta secção apresenta-se um serviço básico de controlo, enquanto na
secção 6.4 será discutida a implementação deste serviço, e um outro para depuração distri- buída, equivalente a outro desenvolvido na primeira DAMS.
proc. proc. debugger sequencial ferramentas ou outros serviços serv.dbg
Figura 4.14: Um serviço para depuração na DAMS
Este será um serviço local, e responsável por disponibilizar em cada máquina, um con- junto de comandos para controlo dos processos, com vista à sua depuração, a partir de qual- quer outra máquina na DAMS. Estas operações correspondem a tornar remotamente acessí- veis as operações habitualmente suportadas pelos tradicionais depuradores sequenciais (de- buggers como p.e. gdb), sendo em princípio, através da interacção com estes depuradores que se podem assim controlar os processos presentes em cada máquina (ver figura 4.14). Este é um exemplo da situação em que um actuador (neste caso o depurador sequencial) é integrado na infraestrutura DAMS por meio de um serviço que lhe serve de interface ou intermediário.
Pode-se, à partida, identificar dois tipos de interacções entre as ferramentas ou outros serviços e este serviço para controlo. Por um lado, a invocação de operações para actuar sobre os processos da aplicação, como por exemplo: parar, continuar, colocar um ponto de paragem7, etc. Por outro lado a necessidade de passar informação à entidade cliente, sobre
alterações no estado das computações controladas, como seja: parou num ponto de para- gem. O primeiro aspecto é suportado pela interface oferecida pelo serviço que realiza uma API com todas as operações a suportar. O segundo aspecto é realizado recorrendo ao meca- nismo de canais de eventos. Para este último, cada instância do serviço em cada máquina, será responsável pela criação de um canal de eventos próprio, através do qual propaga no- tificações de todas as alterações assíncronas detectadas pelos depuradores sequenciais. A entidade cliente pode, em resposta às notificações recebidas, actualizar o seu estado interno, ou a informação oferecida ao utilizador final, no caso de uma ferramenta.
4.7. Exemplos de serviços 99
Várias ferramentas podem tirar partido desta infraestrutura e destes comandos, contro- lando os vários processos. Por outro lado, estas ferramentas podem mais facilmente ser usa- das em aplicações que se executam sobre outras plataformas, desde que a interface oferecida pelo serviço na infraestrutura DAMS se mantenha inalterada.
Como a DAMS permite que vários clientes (logo, ferramentas) acedam a cada serviço, temos a partilha do estado de cada processo sob o controlo deste serviço entre os vários clientes. Tirando partido do mecanismo de difusão de eventos, todos os clientes podem receber “notificações” de alterações relevantes no estado da computação, sendo estas auto- maticamente propagadas aos vários clientes (p.e. para sincronizarem as respectivas visões do estado da aplicação, de cada vez que um processo pára ao atingir um ponto de paragem).
As operações a considerar são:
Attach( pid) — permite a ligação a um processo específico. Corresponde efectuar as inici- alizações necessárias para que o referido processo possa passar a ser controlado;
Detach( pid) — permite libertar o processo indicado do controlo do serviço; Stop(pid) — pede a paragem da execução do processo indicado;
Step(pid) — avança uma instrução no processo indicado (préviamente parado); Continue(pid) — continua a execução do processo, que antes estava parado;
SetBreakpoint(pid, breakpoint) — coloca um pondo de paragem no processo indicado. O breakpointtem a indicação do ficheiro fonte e linha onde o programa deve parar.
DelBreak(pid, breakpoint) — remove o ponto de paragem indicado;
GetBacktrace(pid) — obter a lista das funções activadas na pilha de execução (backtrace); GetValue( pid, var) — obter o valor da variável indicada;
SetValue( pid, var, value) — alterar o valor da variável indicada.
Além destas, existe ainda a possibilidade de requerer acesso a um canal de eventos es- pecífico, através do qual este serviço anuncia acontecimentos assíncronos que ocorrem nos processos sob o seu controlo:
EvCh GetEvCh() — obter o identificador do canal de eventos deste serviço.
Através deste canal prevêem-se as notificações na alteração do estado da execução da com- putação.
Este tipo de controlo é suficientemente poderoso para permitir a implementação de outro tipo de ferramentas. Este tipo de funcionalidades abrangem os requisitos das usadas no desenvolvimento de sistemas para steering [124], replay de aplicação distribuídas [82], teste sistemático da aplicação [84, 34, 35], etc. . .
4.8
Conclusão
Neste capítulo foi proposto um modelo e uma arquitectura abstracta de suporte às ac- tividades de monitorização e controlo de aplicações distribuídas. O modelo propõe uma organização flexível e extensível, baseada num núcleo sobre o qual se executam o conjunto aberto de serviços, que realizam as funcionalidades específicas a cada cenário de monitori- zação. Cabe aos serviços possibilitar, dependendo de cada caso em particular, o modo como as ferramentas podem tirar partido das funcionalidades oferecidas e como as podem parti- lhar. Por outro lado, procura-se facilitar o desenvolvimento das ferramentas, assim como disponibilizá-las nos mais variados ambientes de aplicações paralelas e distribuídas.
Capítulo 5
Implementação da arquitectura DAMS
Neste capítulo são descritas as dimensões da implementação de infraestruturas que suportam o modelo da DAMS. São também referidas as abordagens seguidas na implementação de dois protótipos sobre duas plataformas computacionais diferentes.
5.1
Introdução
Como já foi referido, um primeiro protótipo do modelo DAMS foi desenvolvido, sendo a partir deste que a vantagem de um sistema deste tipo foi reconhecida e que se concebeu então o modelo apresentado no capítulo anterior. Estes trabalhos podem ser resumidos nos seguintes pontos:
1. um primeiro protótipo já referido, implementado sobre a plataforma PVM, que per- mitiu verificar a vantagem de uma plataforma comum no desenvolvimento de diversas ferramentas, que permitiu realizar diversas experiências da sua utilização;
2. um segundo protótipo, implementado pelo autor com base no modelo proposto no ca- pítulo 4, e o principal tema deste capítulo. Além de manter as vantagens já reconheci- das no protótipo anterior, mantendo válidas as experiências antes realizadas (algumas foram trivialmente convertidas para este novo protótipo), permitiu a implementação de novos serviços e o ensaio de novas situações de aplicação.
Neste capítulo discutem-se os principais aspectos da implementação do protótipo se- gundo o novo modelo proposto para a DAMS, sobre uma plataforma Corba (no caso, a implementação ORBit). Esta plataforma revelou-se vantajosa para facilitar a implementação mas, dada a separação mantida entre o nível da plataforma e os níveis superiores da arquitec- tura da DAMS, outras plataformas poderão vir a ser usadas. É descrito também, o primeiro protótipo, onde a plataforma usada foi o PVM, discutindo-se os aspectos particulares da utilização desta plataforma.