Framework para Implementação dos Protocolos de Simulação

A figura 4.2 mostra o diagrama de classes do pacote framework (n˜ao foi atri- bu´ıdo nome para esse framework ). Estas classes constituem o cerne de funciona- mento do framework, possibilitando `as classes dos pacotes espec´ıficos estendˆe-las e estabelecer funcionalidades pr´oprias inerentes ao protocolo que implementam. Nos diagramas seguintes, n˜ao s˜ao representados os m´etodos getters e setters, nem m´e-

Figura 4.1: Representa¸c˜ao esquem´atica do framework

todos que implementam funcionalidades auxiliares e com relevˆancia local restrita `

a pr´opria classe em que ´e definido.

Neste diagrama, duas interfaces se destacam: MessageTypes e Commu- nication. A fun¸c˜ao dessas interfaces ´e estabelecer um padr˜ao de comunica¸c˜ao durante a simula¸c˜ao. A interface Communication estabelece os m´etodos que possibilitar˜ao a comunica¸c˜ao entre os processos da simula¸c˜ao, ao passo que a inter- face MessageTypes padroniza os r´otulos das mensagens utilizadas na ferramenta. Como a ferramenta desenvolvida neste trabalho utiliza a biblioteca de comunica¸c˜ao MPI, os m´etodos especificados em Communication precisam seguir as diretivas do padr˜ao MPI para o envio e recebimento de mensagens. Para tanto, a classe MPICommunication implementa a funcionalidade dessa interface, aplicando as diretivas do MPI `as assinaturas dos m´etodos definidos.

A classe abstrata Process implementa a interface MessageTypes, estendendo para todos os processos da simula¸c˜ao a padroniza¸c˜ao de r´otulos para as mensagens que trafegar˜ao na rede. Essa padroniza¸c˜ao ´e estendida para todos os processos que participam da execu¸c˜ao da simula¸c˜ao distribu´ıda, seja o processo observador, definido pela classe abstrata ControllerProcess, ou um processo que represente o modelo simulado, definido pela classe abstrata SimulationProcess. Essas classes definem funcionalidades b´asicas necess´arias ao andamento da simula¸c˜ao, uma vez que o mecanismo de c´alculo do GVT, desenvolvido para esta ferramenta, requer um processo observador para o seu c´alculo, para ambos os protocolos.

Figura 4.2: Diagrama de classes do pacote framework

Como o mecanismo prop˜oe-se a efetuar a troca entre protocolos, as classes Simulation e Controller foram modeladas para abarcar instˆancias de subclas-

ses das classes SimulationProcess e ControllerProcess, respectivamente, de modo que possam controlar, durante a mudan¸ca de intervalos, a troca de proto- colos, quando for mais vantajosa. As classes Simulation e Controller estendem funcionalidades da classe abstrata Scope, incluindo o m´etodo abstrato initExe- cution(), respons´avel por inicializar a simula¸c˜ao para os processos da simula¸c˜ao e para o processo observador. A classe Scope armazena as informa¸c˜oes de inicia- liza¸c˜ao que precisam ser carregadas para cada processo ao in´ıcio da simula¸c˜ao, ou seja, um vetor de controle que sinaliza qual protocolo deve ser executado em cada intervalo (no caso de uma linha de execu¸c˜ao h´ıbrida) e um contador que indica em qual intervalo a simula¸c˜ao se encontra.

A classe Report ´e respons´avel por registrar os dados de desempenho em cada intervalo de simula¸c˜ao e o total, considerando os dados de todos os intervalos, ao final de sua execu¸c˜ao ap´os a chamada dos m´etodos de registro: logData() e logDataInterval(). A classe Report ´e associada `a classe Scope, n˜ao obstante, tanto as classes Simulation e Controller possuem uma instˆancia desta classe, usando-a para anotar os dados de desempenho dos intervalos ou para compilar os dados totais de todos os processos, respectivamente.

Como cada protocolo possui suas particularidades em rela¸c˜ao `as informa¸c˜oes a serem salvas no decorrer da simula¸c˜ao, as classes StateSaver, State e Event foram modeladas como abstratas. Isso permite que as suas subclasses herdem as suas informa¸c˜oes b´asicas e essenciais ao funcionamento da simula¸c˜ao, e adicionem atributos extras inerentes ao funcionamento de cada protocolo. A classe State- Saver possui uma referˆencia na classe Simulation, e ´e definida, a priori, para as seguintes finalidades: (1) armazenar a ´ultima semente de n´umero aleat´orio gerada na simula¸c˜ao; (2) disponibilizar um m´etodo randomize() respons´avel por gerar novos n´umeros aleat´orios; (3) definir m´etodos a serem implementados pelas suas subclasses para a convers˜ao de dados entre protocolos, item explicado nas se¸c˜oes seguintes. As classes que estendem a classe StateSaver, para cada protocolo, s˜ao respons´aveis pelo salvamento de estados da simula¸c˜ao, uma vez que cada protocolo possui suas estruturas de dados pr´oprias para o armazenamento de estados salvos e, consequentemente, dos seus eventos.

cotes espec´ıficos de cada protocolo. Esta classe funciona similarmente `a uma classe “factory”, com a diferen¸ca que seus m´etodos n˜ao criam novos objetos ao serem in- vocados, mas apenas retornam o objeto ´unico correspondente `a classe em quest˜ao. Isso ocorre devido ao fato de algumas classes, tanto do pacote framework como dos pacotes espec´ıficos, foram constru´ıdas de acordo com o padr˜ao de projetos Single- ton (FREEMAN et al., 2004;GAMMA et al., 1995), por uma quest˜ao de economia de

mem´oria. Neste padr˜ao, a classe em quest˜ao s´o pode ter um objeto instanciado. As classes que se utilizam deste padr˜ao s˜ao: Simulation, Controller, MPI- Communication, e as subclasses de SimulationProcess, ControllerProcess e StateSaver. A classe Signature tamb´em armazena os dados de inicializa¸c˜ao, mantendo uma referˆencia para InitInfo que cont´em o n´umero de processos e o id do processo.

4.2.2 Time Warp

O pacote timewarp est´a representado no diagrama da figura 4.3. Neste di- agrama, a classe TWObserver implementa as funcionalidades do m´etodo exe- cute(), herdado da superclasse ControlleProcess que, de forma an´aloga, o herda da sua superclasse Process. De modo an´alogo, a classe TWProcess implementa as funcionalidades do m´etodo execute(), herdado da superclasse Simulation- Process, com a diferen¸ca de que esta classe comporta uma thread apenas para o recebimento e tratamento de mensagens, pois ´e necess´ario que esta atividade ocorra em paralelo com o processamento da lista de eventos futuros pelo m´etodo execute(). A classe TWProcess possui ainda uma instˆancia de TWStateSa- ver, respons´avel pelo salvamento e recupera¸c˜ao de estados em cada processo, al´em de armazenar a lista atual de eventos futuros. Esses estados, por sua vez, s˜ao modelados pela classe TWState, que armazena os atributos de sua superclasse State e a lista de eventos futuros correspondente `aquele estado. Os eventos s˜ao representados aqui pela classe TWEvent, que estende a classe Event e armazena o identificador(id ) do seu processo criador.

Para que o mecanismo de rollback funcione no Time Warp, ´e necess´ario que haja uma estrutura de antimensagens em cada processo da simula¸c˜ao. A classe

Message representa uma antimensagem no sistema. Esta classe armazena o evento enviado para outro processo e a id do processo para onde foi enviado.

Um detalhe importante ´e que as classes TWEvent, TWState e TWState- Saver possuem um m´etodo convert(). Esses m´etodos s˜ao necess´arios durante a transi¸c˜ao do protocolo Time Warp para o protocolo Rollback Solid´ario. Essas classes, por conterem informa¸c˜oes que devem persistir na mudan¸ca de intervalos, precisam de um modo de passar suas informa¸c˜oes para estruturas espec´ıficas do outro protocolo.

Figura 4.3: Diagrama de classes do pacote timewarp

4.2.3 Rollback Solidário

O pacote solidaryrollback est´a representado no diagrama da figura 4.4. A implementa¸c˜ao deste protocolo ocorre de forma an´aloga `a implementa¸c˜ao do Time Warp, de modo que suas classes SREvent, SRState e SRStateSaver tamb´em possuem m´etodos de convers˜ao para estruturas correspondentes no protocolo Time

Warp. A classe SRObserver e SRProcess, de maneira an´aloga `a implementa¸c˜ao do Time Warp, estendem, respectivamente, as funcionalidades das classes Con- trolleProcess e SimulationProcess, e implementam seus m´etodos execute(). A classe SRProcess, assim como a classe TWProcess, possui uma thread para recebimento e tratamento de mensagens, que executa paralelamente com o m´etodo execute().

Figura 4.4: Diagrama de classes do pacote solidaryrollback

A maior diferen¸ca entre os dois protocolos est´a na forma como efetuam o procedimento de rollback. O protocolo Rollback Solid´ario n˜ao necessita de anti- mensagens, portanto n˜ao precisa armazenar uma lista delas. Isso significa que sua implementa¸c˜ao n˜ao requer uma classe Message como na implementa¸c˜ao do Time Warp, entretanto, o procedimento de rollback no Rollback Solid´ario requer uma maior participa¸c˜ao do processo observador. A classe TWObserver possui listas para trˆes outras classes: RecoveryLine, RollbackInfo e CalculeGVTInfo. A classe RecoveryLine armazena uma linha de recupera¸c˜ao, extra´ıdo da diagonal

principal da matriz de checkpoints. A classe RollbackInfo ´e usada para “agen- dar” rollbacks, como forma de evitar rollbacks simultˆaneos, desta forma um rollback agendado s´o ´e executado quando a opera¸c˜ao de rollback anterior j´a tiver finalizada. De forma an´aloga, a classe CalculeGVTInfo ´e usada para “agendar” solicita¸c˜oes de c´alculo de GVT. As solicita¸c˜oes agendadas s´o s˜ao efetuadas ap´os o t´ermino da ´

ultima opera¸c˜ao de rollback ser finalizada.