Processes. Chapter 3 PROCESSOS. O capitulo anterior concentrou-se na comunicação em Sistemas Distribuídos.

Transcrição

1 Processes Chapter 3 PROCESSOS O capitulo anterior concentrou-se na comunicação em Sistemas Distribuídos. Essa comunicação acontece entre processos e eles são fundamentais em SDs. O conceito de processos origina-se em Sistemas Operacionais tradicionais onde ele é definido como um programa em execução.

2 THREADS SOs tradicionais --> cada processo tem um espaço de endereçamento e um único fluxo de controle. Existem situações onde é desejável ter múltiplos fluxos de controle partilhando o mesmo espaço de endereçamento. PROCESSO TRADICIONAL processos Cada processo tem seu próprio contador de programa, pilha, registradores, e espaço de endereçamento.

3 THREADS (Processos Leves) thread processo THREADS (Características) Execução estritamente seqüencial, tem seu próprio contador de programa, pilha; Partilham a CPU do mesmo modo que os processos; Em um multiprocessador eles podem executar em paralelo; Eles podem criar threads filhos e ficam bloqueados como processos; Todos os threads tem o mesmo espaço de endereçamento (portanto as mesmas variáveis globais).

4 THREADS (Segurança) Um thread pode ler e escrever na pilha de outro thread. Não existe proteção porque: 1- É impossível; 2- Não é necessário, diferente de processos que podem pertencer a diferentes usuários, os threads são sempre de um mesmo usuário. Conceito de Thread e Processo threads Contador de Prog. Pilha Registradores Threads Filhos Estado processos Espaço de Endereçam. Variáveis Globais Arq. Abertos Processos Filhos Temporizadores Sinais Semáforos Da mesma forma que processos, um thread pode estar em um dos seguintes estados: executando, bloqueado, pronto ou terminado.

5 Uso do Thread Foram criados para permitir que o paralelismo seja combinado com execução seqüencial e chamadas bloqueantes do sistema. Consideremos o exemplo do servidor de arquivo. cache mailbox kernel modelo despachador/trabalhador THREADS (modelo despachador/trabalhador) O thread despachador lê requisições de um sistema de mailbox. Após examinar a requisição, ele escolhe um thread trabalhador desocupado, para quem passa a requisição. O thread despachador então acorda o thread trabalhador (que pode estar bloqueado em um semáforo, por exemplo). Quando o trabalhador ficar bloqueado outro thread assumirá o estado de executando.

6 Organização de Threads cache mailbox modelo de time kernel Organização de Threads cache mailbox kernel modelo de pipeline

7 O Problema do Servidor de Arquivos Resolvido sem Threads Solução 1 - Operando com um processo tradicional. O servidor de arquivo pega uma requisição, executa até ela ser completada antes de ir para a próxima. Enquanto espera pelo disco o servidor espera desocupado e não processa nenhuma outra requisição. O Problema do Servidor de Arquivos Resolvido sem Threads Solução 2 - Executando o servidor como uma máquina de estado finito. Quando uma requisição chega, um processo a examina. Se ela não pode ser satisfeita do cache, uma mensagem é enviada para o disco. Entretanto, ao invés de bloquear, ele registra o estado corrente da requisição em uma tabela e pega a próxima requisição. Se ela for uma resposta do disco, as informações da tabela devem ser usadas para restaurar o estado de computação e a resposta processada (De fato o que está acontecendo é uma simulação dos threads).

8 THREADS (Resumo do Conceito) Threads tornam possível manter a idéia de processo seqüencial que usa chamadas bloqueantes, e ao mesmo tempo conseguir paralelismo. Chamadas bloqueantes tornam a programação mais fácil e o paralelismo aumenta a performance. Implementação de Threads 1- Implementação em espaço do usuário espaço do usuário T0 T1 T2 T3 T4 T5 T6 run time system kernel

9 THREADS (Implementação) Uma das possibilidades é colocar os threads inteiramente na área do usuário. O kernel não tem conhecimento deles (para ele são processos comuns). grande vantagem é poder ser implementado em SOs que não tem threads o chaveamento de threads é mais rápido do que se for feito pelo kernel permite que cada processo tenha o seu algoritmo de escalonamento Problemas: 1) como permitir chamadas bloqueantes (objetivo dos threads: processo seqüencial+chamadas bloqueantes + paralelismo); 2) se um thread não ceder à CPU ele executa quanto quiser. Implementação de Threads 2- Implementação no kernel espaço do usuário T0 T1 T2 T3 T4 T5 T6 kernel

10 THREADS (Implementação) Não tem run time system. Quando um thread precisa ser criado ou destruído, basta fazer uma chamada para o kernel. Para gerenciar os threads, o kernel tem uma tabela para cada processo com uma entrada por thread. Cada entrada tem: registros, estado, prioridade e outras informações Alguns sistemas reciclam seus threads para diminuir o overhead. THREADS (Problemas de Implementação) Threads no espaço do usuário: Custa menos (basicamente o custo de alocar e desalocar memória para a pilha do thread); O chaveamento de contexto entre threads émais rápido; grande problema: a invocação de uma chamada bloqueante irá bloquear o processo todo ao qual o thread pertence, e desta forma todos os outros threads do processo; Esses problemas podem ser superados implementando os threads a nível de kernel mas o preço é mais alto em termos do overhead. A solução é a implementação híbrida de threads a nível de usuário e nível de kernel.

11 Thread Implementation (Nível de Kernel e Usuário) Combining kernel-level lightweight processes and user-level threads. THREADS em Sistemas Distribuídos Threads permitem chamadas bloqueantes sem bloquear o processo inteiro. Esta propriedade faz o thread atrativo para ser usado em sistemas distribuídos, uma vez que fica mais fácil expressar comunicação mantendo múltiplas conexões lógicas ao mesmo tempo. Isto será ilustrado com os clientes e servidores multithread

12 CLIENTES MULTITHREADED Usualmente o modo de esconder a latência da comunicação é iniciar a comunicação e imediatamente prosseguir com alguma outra coisa. Exemplo: Web browsers. Usando clientes multithreaded, conexões podem ser estabelecidas com diferentes réplicas, permitindo que dados sejam transferidos em paralelo. SERVIDORES MULTITHREADED Embora existam importantes benefícios em clientes multithreaded, o maior uso de multithreading em S.Ds. é encontrado no lado servidor. A prática tem mostrado que multithreading não somente simplifica a implementação do servidor consideravelmente, mas também torna muito mais fácil desenvolver servidores que explorem paralelismo para obter alta performance.

13 Multithreaded Servers (1) A multithreaded server organized in a dispatcher/worker model. Multithreaded Servers (2) Model Characteristics Threads Single-threaded process Finite-state machine Parallelism, blocking system calls No parallelism, blocking system calls Parallelism, nonblocking system calls Three ways to construct a server.

14 Client-Side Software for Distribution Transparency A possible approach to transparent replication of a remote object using a client-side solution. Servers: General Design Issues 3.7 a) Client-to-server binding using a daemon as in DCE b) Client-to-server binding using a superserver as in UNIX

15 Object Adapter (1) Organization of an object server supporting different activation policies. Razões para Migração de Código Tradicionalmente, migração de código em SDs se dá na forma de migração de processo, no qual um processo inteiro é movido de uma máquina para outra. Mover um processo que está rodando para outra máquina é um processo custoso. A razão para migração de código tem sido sempre a performance. A idéia básica é que a performance do sistema como um todo aumenta se processos são movidos de uma máquina sobrecarregada para uma com pouca carga.

16 Reasons for Migrating Code The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server. Models for Code Migration Alternatives for code migration. Weak mobility transfere código + dado de inicialização Strong mobility - também transfere segmento de execução

17 Software Agents Um Agente de software é um processo autônomo capaz de reagir e iniciar mudanças no ambiente, possivelmente com usuários e outros agentes. A característica que faz do agente mais que um simples processo é a sua capacidade de agir por ele próprio e tomar iniciativas quando apropriado. Um Agente Colaborativo é um agente que é parte de um sistema multiagente, onde cada agente procura atingir algum objetivo comum. Software Agents (Cont.) Um Agente Móvel é um agente que tem a capacidade de se mover entre diferentes máquinas.

18 Software Agents in Distributed Systems Property Autonomous Reactive Proactive Communicative Continuous Mobile Adaptive Common to all agents? Yes Yes Yes Yes No No No Description Can act on its own Responds timely to changes in its environment Initiates actions that affects its environment Can exchange information with users and other agents Has a relatively long lifespan Can migrate from one site to another Capable of learning Some important properties by which different types of agents can be distinguished. Tecnologia de Agentes FIPA Foundation for Intelligent Physical Agents propos um modelo geral para Agentes de Software. Uma plataforma para Agentes fornece serviços básicos necessários em qualquer sistema multiagente. Essas facilidades são: criação e eliminação de agentes, serviços para localização de agentes e serviços para comunicação entre agentes. ACC Agent Communication Channel

19 Agent Technology The general model of an agent platform (adapted from[fipa98-mgt]). ACC Agent Communication Channel para a comunicação entre plataformas diferentes