Sistemas Distribuídos

PROCESSOS E THREADS

Professor.: Dalton Matsuo Tavares

06/04/11
 RECAPITULANDO...

PROCESSOS/THREADS EM SISTEMAS
NÃO DISTRIBUÍDOS

06/04/11
 Definição

● Processo é um programa em execução,

acompanhado dos valores atuais do contador de
programa, dos registradores e das variáveis.
● Processo != Programa
● Cada processo está associado ao seu espaço de
endereçamento, uma lista de posições de
memória.
● O espaço de endereçamento contém o programa
executável, os dados do programa e sua pilha;
informações necessárias para executar um
programa.

06/04/11
 RECAPITULANDO...
● Informações relacionadas a processos
ficam guardadas em uma tabela de
processo no SO (em caso de
suspensão, por exemplo).

06/04/11
 Paralelismo
● Múltiplas tarefas executadas “ao mesmo
tempo”. Ex.: ler dados de um disco, mostrar
texto na tela, enviar texto para a impressora,
etc.
● Considerando um sistema multiprogramado, a
CPU salta de programa, em dezenas ou
centenas de milissegundos
● A cada instante a CPU executa apenas um
programa – pseudoparalelismo.

06/04/11
 Modelo de Processo

Multiprogramação de quatro programas

06/04/11
 Criação de Processos
● Principais eventos que levam à criação de
processos
1. Início do sistema
2. Execução de chamada ao sistema de criação de
processos
3. Solicitação do usuário para criar um novo processo
4. Início de um job em lote
● No Unix usa-se a chamada de sistema fork para
criação de processos.
Ex.: fork-ex.c
● No Windows, CreateProcess.
06/04/11
 Criação de Processos
(cont)
● Após a criação de um processo, pai e filho
possuem espaços de endereçamento
distintos.
● Se um dos dois processos modificar uma
palavra em seu espaço de endereçamento,
a mudança não é visível ao outro.
● Particularidades: no Unix o espaço de
endereçamento inicial é uma cópia do pai
pro filho, no Windows, o espaço de
endereçamento é diferente desde o início.
06/04/11
 Hierarquia de Processos
● Pai cria um processo filho, processo
filho pode criar seu próprio processo
● Formam uma hierarquia
➢ UNIX chama isso de “grupo de processos”
● Windows não possui o conceito de
hierarquia de processos
➢ Todos os processos são criados iguais

06/04/11
 Estados de Processos

06/04/11
 Estados de Processos (cont)

● Possíveis estados de processos

➢ Em execução (realmente usando a CPU)
➢ Bloqueado (incapaz de executar enquanto um
evento externo não ocorrer – chamadas block
ou pause)
➢ Pronto (executável; temporariamente parado
para dar lugar a outro processo).

06/04/11
 Processos x Threads

06/04/11
 Processos x Threads (cont)
● Processo é uma forma de agrupar
recursos relacionados.
➢ Espaço de endereçamento contém arquivos
abertos, processos filhos, alarmes pendentes,
tratadores de sinal, etc.
➢ Colocá-los todos juntos facilita o gerenciamento
desses recursos.

06/04/11
 Processos x Threads (cont)
● Thread != Processo.
➢ Executado dentro de um processo, porém
ambos podem ser tratados separadamente.
● Processos são usados para
agrupar recursos.
● Threads são as entidades
escalonadas para a execução
sobre a CPU.

06/04/11
 Processos x Threads (cont)
● Threads permitem que múltiplas execuções
ocorram no mesmo ambiente do processo
com um alto grau de independência uma
da outra.
● Ter múltiplos threads executando em
paralelo em um processo é análogo a ter
múltiplos processo executando em paralelo
dentro de um mesmo computador.
● São comumente chamados de processos
leves (lightweight process).
06/04/11
 Processos x Threads (cont)
● Threads compartilham o mesmo espaço de
endereçamento de um processo.
➢ Processos possuem espaços de endereçamento
diferentes entre si.
● Compartilham as mesmas variáveis globais.
● Pode ler, escrever ou mesmo apagar a pilha
de outro thread.
● Não há proteção entre threads.
➢ Processos possuem proteção entre si.

06/04/11
 Processos x Threads (cont)
● Processos podem pertencer a múltiplos
usuários, potencialmente hostis.
● Threads não possuem relação com o clock
externo. Devem ser “educadas” cedendo a
CPU de tempos em tempos de modo que
outras threads possam executar.
● Threads possuem um contador de programa
que mantém o controle de qual instrução deve
executar em seguida.
● Threads possuem registradores que contém
suas variáveis atuais de trabalho.
06/04/11
 Processos x Threads (cont)
● Threads apresentam uma pilha que traz a
história da execução, com uma estrutura para
cada procedimento chamado mas ainda não
retornado.
● Multithreading x forking
➢ Multithreading permite concorrência nativa
em um dado processo (múltiplos threads
em execução).
➢ Em processos, caso uma chamada
bloqueante seja feita, a característica de
processamento sequencial fica evidente.
06/04/11
 Processos x Threads (cont)
● Multithreading x forking
➢ Ex. Planilha eletrônica com múltiplos
campos interdependentes. Processo
monothread precisa aguardar entradas para
habilitar outras operações. Múltiplos
threads – uma para interface com o usuário,
outra para atualizar campos, outra para
efetuar uma cópia de segurança em disco.

06/04/11
 Processos x Threads (cont)
● Como threads não possuem recursos
atribuídos a elas, são mais fáceis de criar e
destruir do que processos.
➢ Em muitos sistemas, criar threads é centenas de vezes
mais rápido do que criar processos.
● Threads não apresentam nenhum ganho de
desempenho, considerando que sejam
atrelados a CPU, mas quando existe
computação substancial e também I/O, o uso
de threads permite que estas atividades se
sobreponham, agilizando a aplicação.

06/04/11
 Processos x Threads (cont)
● Threads são úteis em sistemas com múltiplas
CPUs, onde paralelismo real é possível.
➢ Cada thread pode ser designado a uma CPU diferente,
enquanto dados compartilhados podem ser armazenados em
memória principal compartilhada.
● Processos podem ser usados para
desenvolvimento de grandes aplicações, onde
estas podem ser compostas por programas
cooperativos, cada qual executando em um
processo distinto. A comunicação pode ser feita
usando IPC – named pipes, filas de mensagens,
memória compartilhada etc. PROBLEMA: excessivo
chaveamento de contexto.
06/04/11
 Processos x Threads (cont)

Chaveamento de contexto como resultado de IPC.

06/04/11
 Processos x Threads (cont)
● Implicações de IPC:
1) Salvar o mapa de memória (MMU) → descarregar o TLB
2) Chaveamento de processo
3) Carregar novo mapa de memória (MMU) → carregar o novo TLB.
● POSSIBILIDADE: criar uma aplicação que use
threads separados para implementar módulos
diferentes. Comunicação pode ser feita via
utilização de dados compartilhados. Chaveamento
pode ser feito inteiramente em espaço de usuário.
➢ O núcleo pode estar ciente da existência de
threads e realizar o escalonamento.

06/04/11
 Processos x Threads (cont)

06/04/11
 Processos x Threads (cont)

06/04/11
 Processos x Threads (cont)
● Espaço de usuário
➢ Barato criar/destruir threads – determinado pela
facilidade de alocar/liberar memória para ajustar a pilha
da thread.
➢ Administração mantida no espaço de endereçamento do
usuário.
➢ Chaveamento de contexto pode ser feito em poucas
instruções. Não há necessidade de mudar mapas de
memória, liberar a TLB, rastreamento da CPU etc.
➢ Chaveamento de contexto ocorre quando threads
precisam sincronizar. Ex. para compartilhar dados.
➢ Desvantagem: chamada de sistema para I/O
bloqueia o processo inteiro.
06/04/11
 Processos x Threads (cont)
● Espaço de kernel
● Resolve o problema quanto a chamadas bloqueantes.
● Desvantagem: cada operação (criação, remoção,
sincronização etc) será realizada pelo kernel.
● Chaveamento de contexto de threads é tão caro quanto
o chaveamento de processos.
● Solução: forma híbrida (lightweight processes – LWP).

06/04/11
 Implementação de Threads

● Pacote de threads pode ser compartilhado

por múltiplos LWPs.
● O pacote de thread possui uma única
rotina para escalonar a próxima thread ao
criar um LWP (por meio de uma chamada
de sistema).
● O LWP recebe sua própria pilha e é instruído a
executar a rotina de escalonamento em busca de
uma thread para executar.
● Se existem vários LWPs, cada um deles executa o
escalonador.
06/04/11
 Implementação de Threads (cont)

● A tabela de thread é usada para manter o conjunto

corrente de threads, compartilhado pelos LWPs.
● A proteção desta tabela para garantir acesso exclusivo
por meio de mutexes, são implementados inteiramente
no espaço de usuário → escalonamento de LWPs não
requer suporte do kernel.
● Quando um LWP encontra uma thread executável, ele
chaveia o contexto para aquela thread. Enquanto isso,
outros LWPs podem estar procurando outras threads
executáveis.
– Ex. em caso de bloqueio em um mutex ou variável de condição,
faz-se a administração necessária e se chama a rotina de
escalonamento. Encontrando-se outra thread, faz-se o
chaveamento de contexto. O chaveamento de contexto é
implementado inteiramente em espaço de usuário.

06/04/11
 Implementação de Threads (cont)

● Chaveamento ENTRE LWPs requer suporte do

kernel (chaveamento user → kernel → user).
Isso só acontece quando um LWP não tem
condições de continuar.
● Vantagens:
➢ Criar, destruir, sincronizar threads é um procedimento
barato – sem intervenção do kernel.
➢ Considerando que o processo possua LWPs suficientes,
em caso de chamada bloqueante, o processo não
bloqueará.
➢ Uma aplicação não precisa saber da existência dos LWPs.
Tudo que ele enxerga são threads de espaço de usuário.
06/04/11
 Implementação de Threads (cont)

➢ LWPs podem ser facilmente utilizadas em ambientes de

multiprocessadores. Cada LWP pode ser implementado
em uma CPU diferente.
● Desvantagem:
➢ Criar LWPs continua tão caro quanto em threads em nível
de kernel – tarefa realizada ocasionalmente.
● Opção a LWPs: ativações de escalonador
(scheduller activations). Em caso de chamada
bloqueante realiza um upcall para o
escalonador, de modo que este seleciona
outra thread.

06/04/11
 Processos x Threads (cont)
● No contexto de Sistemas Distribuídos:
threads pop-up

06/04/11
 Processos x Threads (cont)
● Algum planejamento avançado é necessário
ao se usar threads pop-ups.
● Em qual processo a thread é executada?
● O sistema suporta threads executando no contexto do
kernel?
● Em espaço de kernel, o tratamento da thread
geralmente é mais rápido do que em espaço
de usuário.
● Em espaço de kernel uma thread pode facilmente
acessar todas as tabelas do kernel e dispositivos de I/O.
● São perigosas em caso de má codificação.

06/04/11
 PROCESSOS/THREADS EM SISTEMAS
DISTRIBUÍDOS

06/04/11
 Propriedades
● Uma propriedade importante é a possibilidade de
efetuar uma chamada de sistema bloqueante sem
bloquear o processo no qual a thread está
executando.
● Permite a manutenção de várias conexões lógicas
em sistemas distribuídos
● Em redes de longa distância (MANs e WANs) pode
existir a necessidade de mascarar/minimizar
tempos de propagação muito longos em
mensagens interprocessos muito longas (centenas
de milissegundos ou até segundos).

06/04/11
 Propriedades (cont)
● Solução usual é realizar a comunicação e
iniciar alguma outra atividade.
● Ex1. Clientes multithreaded. Navegadores
web (mostrar o conteúdo ainda em
trânsito, conexões keep alive x
paralelismo).
● Considerando a existência de servidores espelhados
(para balanceamento de carga), cada thread do
cliente pode se conectar a um servidor distinto
(dependendo do algoritmo de balanceamento de
carga).

06/04/11
 Propriedades (cont)
● Ex2. Servidores multithreaded

06/04/11
 Propriedades (cont)
● Ex2. Servidores multithreaded

06/04/11
 Virtualização
● Virtualização de recursos.
● Ilusão de existência de múltiplos recursos
quando existe apenas um (ou um número
menor de recursos do que requisições).
● Ex. Processos e threads x CPU (memória
etc)
● Atualmente, estende ou substitui uma
interface existente de modo a imitar o
comportamento de outro sistema.

06/04/11
 Virtualização (cont)

(a) Sistema tradicional.

(b) Sistema A virtualizado sobre sistema B.
06/04/11
 Virtualização (cont)
● Interfaces de um sistema computacional:
1) Interface entre o hardware e o software, consistindo em
instruções de máquina que podem ser invocadas por
qualquer programa.
2) Uma interface entre o hardware e o software, consistindo
em instruções de máquina que podem ser invocadas por
programas privilegiados, como um sistema operacional.
3) Interface de chamadas de sistema, como oferecido por
um S.O.
4) Interface de chamadas de biblioteca, conhecido com API.
Em alguns casos, a API oculta as chamadas de sistema.

06/04/11
 Virtualização (cont)
● Interfaces de um sistema
computacional:

06/04/11
 Virtualização (cont)
● Aplicações
➢ Permitir execução de software legado em hardware
atual.
➢ Virtualização de servidores de aplicação/provisão de
conteúdo. A vantagem é permitir a replicação
dinâmica de conteúdo.
● Arquitetura
➢ Sistema runtime, o qual oferece um conjunto de
instruções que deve ser usado para executar
aplicações (a).
As instruções podem ser interpretadas (eg. Java) ou
–
emuladas (eg. Wine – necessário emular as chamadas de
06/04/11 sistema).
 Virtualização (cont)
● Sistema pode ser implementado como uma camada
encapsulando totalmente o hardware original,
oferecendo a interface completa daquele hardware.
Conhecido como VMM – Virtual Machine Monitor (b).
Ex. VMWare, Virtualbox etc.

06/04/11
 Virtualização (cont)
● Ótima solução considerando questões
de segurança.
● Isolamento de uma aplicação e seu ambiente.
Falhas não afetam a máquina como um todo.
● Portabilidade.

06/04/11
 Clientes

(a) Uma aplicação com seu próprio protocolo.

(b) Uma solução genérica para permitir acesso a aplicações remotas.

06/04/11
 Exemplo: Sistema X Window

06/04/11
 Exemplo: Sistema X Window (cont)

● Aplicações escritas para X devem separar a

lógica de aplicação de comandos de
interface de usuário.
● Na prática não funciona assim.
● Aplicação envia várias requisições, para as quais irá
esperar respostas antes de poder avançar para um
próximo passo.
● Comportamento problemático em redes (MANs e
WANs).
– Solução: reengenharia do protocolo X. Ex. compactação de
mensagens (NX), caching, hospedagem de um servidor X
no lado da aplicação.

06/04/11–
 Software cliente para
transparência de distribuição
● É desejável que um cliente não saiba que está
se comunicando com processos distribuídos.
● Por questões de desempenho e correção, isto
não é desejável no lado servidor.
● Espelhamento de servidores → operações devem ser
realizadas em uma ordem específica.
● Transparência de acesso geralmente é
alcançada por meio de um stub cliente, o qual
define uma interface para o que o servidor
oferece.

06/04/11
 Software cliente para transparência
de distribuição (cont)

● Servidor de nomes: transparências de

localização, migração e relocação. Ex.
Quando um cliente já está ligado a
um servidor, o cliente pode ser
informado quando o servidor muda
de localização.
● Transparência de replicação →
soluções client-side. Ex. Software
cliente pode solicitar/processar
mensagens
06/04/11
a múltiplos servidores.
 Software cliente para transparência
de distribuição (cont)

06/04/11
 Software cliente para transparência
de distribuição (cont)

● Transparência de falha → mascaramento de

falhas é tipicamente realizado pelo
middleware cliente. Ex. Solicitações
automáticas de conexão, tentativa de
conexão a outros servidores etc.

06/04/11
 Servidores
● Servidor é um processo implementando
um serviço específico para prover a uma
coleção de clientes.
● Espera por uma requisição → atende a requisição
● Organização:
● Interativo: o próprio servidor lida com a requisição e
a atende caso necessário.
● Concorrente: não lida com a requisição por si, mas a
encaminha para uma thread ou outro processo.
Aguarda posteriormente novas requisições.

06/04/11
 Servidores (cont)
● Servidores usam endpoints ou portas.
Estas são globalmente conhecidas.
Atribuídas pela IANA (Internet
Assigned Numbers Authority).
● Basta o endereço IP considerando o
conhecimento da porta.
● Transparência alcançável com
serviços de nomes.

06/04/11
 Servidores (cont)

06/04/11
 Servidores (cont)
● Questões quanto a servidores
incluem a interrupção do serviço. ex.
Como interromper uma transferência
após seu início?
● Término, início de nova transferência.
● Comunicação out-of-band.
● Servidor stateless → não mantém informação
sobre o estado dos clientes.
● Servidor statefull → mantém a situação
persistente dos clientes.
06/04/11
 Clusters de Servidores

● Coleção de máquinas conectadas por

meio de uma rede, onde cada
máquina executa um ou mais
servidores.
● Consideramos aqui servidores conectados via
LAN (alta largura de banda e baixa latência).
● Geralmente composto por servidores dedicados
a processamento de aplicação.
● Tipicamente servidores executando em
hardware de alto desempenho.
06/04/11
 Clusters de Servidores (cont)

06/04/11
 Clusters de Servidores (cont)

● Chaveador (switch) é o ponto de entrada

para o cluster de servidores.
● Trabalha com o princípio de TCP handoff.
Repassa uma solicitação de conexão a um
servidor do cluster. Este responde com o
endereço do chaveador.
● Espécie de spoofing. Esse é necessário.
● Importante para balanceamento de carga.
Ex. Round-robin.

06/04/11
 Clusters de Servidores (cont)

06/04/11
 Clusters de Servidores (cont)

● Servidores distribuídos: o conceito de

chaveador, leva a introdução de um
único ponto de falha. Servidores
distribuídos são uma forma de
implementar um conjunto de
máquinas que aparece para o mundo
exterior como uma única máquina.
● Alternativa: implementar o chaveador com
mainframe com MTBF superior a 40 anos.

06/04/11
 Clusters de Servidores (cont)

● ex. suporte a mobilidade para IPv6 (MIPv6). Nó

móvel possui uma rede doméstica e para a qual
possui um endereço associado estável conhecido
como home addres (HoA). Possui um roteador
especial (home agent) o qual cuida de encaminhar
o tráfego para o nó remoto quando este está fora.
Assim, quando o nó se anexa a uma rede externa
(foreign network) ele ganha um endereço
temporário (care-of address – CoA), onde pode ser
alcançado. Aplicações apenas enxergam o endereço
doméstico/estável do nó e não o CoA.
● Mesmo conceito pode ser aplicado a servidores
distribuídos.
● Home agent pode ser um gargalo potencial.
06/04/11
 Clusters de Servidores (cont)

● Solução: route optimization pode ser usado

para fazer que clientes acreditem que estão se
comunicando com um único servidor, quando,
em verdade, cada cliente se comunica com um
nó membro diferente dos servidores
distribuídos.

06/04/11
 Clusters de Servidores (cont)

06/04/11
 Clusters de Servidores
● Gerenciando clusters servidores
● Terminal remoto (monitoramento, instalação e
mudança de componentes)
● Uso de interface administrativa. Vantagem:
operações coletivas podem ser mais facilmente
oferecidas.
– Cluster system management da IBM.
– Não é interessante considerando cluster muito grandes.
● Monitoramento de clusters muito grandes é quase
sempre ad hoc.
– Soluções de auto-gerenciamento a caminho. Ainda pouco
desenvolvido.

06/04/11
 Exemplo: PlanetLab
● http://www.planet-lab.org/
● Sistema distribuído colaborativo
.Organizações doam um ou mais
computadores somando-se centenas de nós.
● Esses computadores formam um cluster de
uma camada (1-tier): acesso, armazenamento
e processamento podem ocorrer em cada nó.
● Componentes: virtual machine monitor (VMM)
e o vserver.

06/04/11
 Exemplo: PlanetLab (cont)
● VMM: sistema operacional Linux
melhorado.
● Assegura que os vservers estão separados
● Vserver: ambiente separado no qual um
grupo de processos executa.
● ex. um vserver com PHP 4 e Apache 1.3.1 e outro
vserver com PHP 5 e Apache 2.
● Conceito de slice: conjunto de vservers,
cada vserver executando em um nó
diferente.
06/04/11
 Exemplo: PlanetLab (cont)

06/04/11
 Exemplo: PlanetLab (cont)
● Abordagem:
● Cada nó é equipado com uma coleção de
sensores. Cada sensor responsável por um
recurso (CPU, disco etc).
● A ideia principal de um vserver é criar um
ambiente isolado. Isso inclui os arquivos que
são normalmente compartilhados por uma
única máquina.
– O isolamento de filesystem pode ser alcançado por
meio do comando chroot.

06/04/11
 Exemplo: PlanetLab (cont)
● Características
● Gerente do nó: cada nó possui este gerente,
implementado por meio de um vserver separado,
cuja tarefa é criar outros vservers em seu nó e
controlar alocação de recurso.
– Não toma decisões quanto a política, é meramente um
mecanismo para oferecer os ingredientes essenciais para
que um programa execute em um dado nó.
– Manutenção de recursos é feita pela especificação de
recursos. Especifica um intervalo de tempo durante o qual
certos recursos foram alocados.
– Recursos são relacionados a slices. Cada slice é associado a
um provedor de serviço, o qual pode ser visto como uma
entidade tendo uma conta no PlanetLab.
06/04/11
 Exemplo: PlanetLab (cont)
● Para criar um novo slice, cada nó irá executar um serviço
de criação de slice (slice creation service – SCS), o qual,
por sua vez, pode contatar o gerente do nó e pedir a ele
para criar um vserver e alocar recursos.
● O gerente do nó não pode ser contatado diretamente por
uma rede para a criação de slices.
● O SCS é contatado para este fim. Apenas entidades
autorizadas (slice authorities) podem solicitar a criação
de slices.
● Um provedor de serviço irá contatar o slice authority e
solicitar a criação de um slice em uma coleção de nós. O
provedor de serviço é conhecido do slice authority, pois
este foi registrado como um usuário PlanetLab.

06/04/11
 Exemplo: PlanetLab (cont)
● Management authorities: é responsável por nós. Garante que
os nós sob sua responsabilidade executem o software básico do
PlanetLab e se adequem as regras do PlanetLab.
● Provedores de serviço acreditam que os nós conhecidos de
management authorities irão se portar adequadamente.

06/04/11
 Exemplo: PlanetLab (cont)
● Relações:
1) Um proprietário de nó coloca seu nó sob o regime
de um management authority, possivelmente
restringindo o uso quando aplicável.
2) Um management authority oferece o software
necessário para adicionar um nó ao PlanetLab.
3) Um provedor de serviço se registra com um
management authority. Oferecendo nós que se
comportem conforme o esperado.
4) Um provedor de serviço contata um slice authority
para criar slices em uma coleção de nós.

06/04/11
 Exemplo: PlanetLab (cont)
● Relações:
(5) O slice authority precisa autenticar o
provedor de serviço.
(6) Um proprietário de nó oferece um
serviço de criação de slices. Ele
essencialmente delega gerenciamento de
recurso ao slice authority.
(7) Um management authority delega a
criação de slices a um slice authority.

06/04/11
 Exemplo: PlanetLab (cont)
● Problemas:
1) Nós pertencem a diferentes organizações. Cada
organização deve estar apta a especificar quem pode
executar aplicações em seus nós e restringir uso de
recurso de maneira apropriada.
2) Existem várias ferramentas de monitoramento
disponíveis, mas elas assumem uma combinação de
hardware e software muito específicas. Além disso, são
desenvolvidas para uso em uma única organização.
3) Programas de diferentes slices mas executando no
mesmo nó não devem interferir entre si. Este problema é
similar à independência de processos em sistemas
operacionais.

06/04/11
 Migração de Código
● Lida com a movimentação de programas entre
máquinas, com a intenção de ter aqueles
programas executados em um alvo.
● Em alguns casos, como em migração de
processo, o status de execução de um
programa, sinais pendentes, e outras partes
do ambiente também precisam ser movidos.
● Como fazer em sistemas heterogêneos?

06/04/11
 Migração de Código (cont)
● Por que migrar código?
● Balanceamento de carga – deslocar processos de
ambiente sobrecarregados para ambientes com
menor carga.
● Ex 1. sistema cliente-servidor no qual o sistema
gerencia uma grande base de dados. Se um cliente
precisa realizar muitas operações no BD,
envolvendo grandes quantidades de dados, seria
interessante migrar o cliente e enviar apenas os
resultados da operação via rede.

06/04/11
 Migração de Código (cont)
● Ex 2. migração de partes de um servidor para o cliente. Preenchimento
de formulários pelo cliente. Migra-se o formulário e transmite-se apenas
o formulário resultante ao servidor.
● Ex 3. agentes móveis.
● Ex 4. configuração dinâmica de clientes. Necessidade por interfaces
padronizadas.

06/04/11
 Migração de Código (cont)
● Definição de processo segundo Fugetta et al.
(1998):
● Segmento de código: parte que contém o
conjunto de instruções que compõe o programa
que está sendo executado.
● Segmento de recurso: contém referências a
recursos externos necessários ao processo (ex.
Arquivos, dispositivos etc).
● Segmento de execução: usado para
armazenar o estado de execução corrente de
um processo, consistindo de dados privados,
pilha e contador de programa.
06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● O mínimo para migração de código é oferecer
mobilidade fraca → transferência do
segmento de código juntamente com dados
de inicialização.
– Um programa é iniciado a partir de uma
de várias posições de início pré-
definidas.
– Requer apenas que a máquina alvo
possa executar o código migrado.
– ex. Java applets.
06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● Mobilidade forte →segmento de execução
também pode ser transferido.
– Um processo pode ser parado,
subsequentemente movido para outra
máquina e então continuar sua execução
onde parou.
– Mais geral, porém mais complexo de
implementar do que mobilidade fraca.

06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● Iniciado por emissor → iniciado na máquina onde
o código reside ou está sendo executado no
momento. ex. Envio de programas a um servidor de
computação, programa de busca pela Internet
direcionado a uma base de dados etc. Exige que o
emissor tenha sido previamente cadastrado –
questões de segurança.
● Iniciado por receptor → iniciativa tomada pela
máquina alvo. ex. Java applets. Pode ser feito
anonimamente. Mais simples de implementar.

06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● ex. cloning remoto. Em contraste com
migração de processo, o processo de cloning
produz uma cópia exata do processo original,
porém agora executando em uma máquina
diferente.
● Processo clonado é executado em paralelo ao processo
original.
● Em sistemas Unix, isso é alcançado fazendo o fork de um
processo filho e deixar que este execute em paralelo ao
processo original, agora executando em uma máquina
remota.
06/04/11
 Migração de Código (cont)
● ex. cloning remoto.
● Vantagem: o modelo se assemelha àquele que já é
usado em muitas aplicações. A diferença é que o
processo clonado é executado em uma máquina
diferente.
● Maneira simples de alcançar transparência de
distribuição.

06/04/11
 Migração de Código (cont)

06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● Até agora consideramos apenas o
segmento de código e execução. O
segmento de recurso requer atenção
especial.
– ex. suponha que um processo
mantenha referência a uma porta TCP,
por meio da qual estava em
comunicação com outros processos
remotos → mantido no segmento de
recurso.
06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● Tipos de vinculações de recursos
(resource bindings)
– Referência a recurso por um identificador.
Referência forte. ex. URL, IP e porta.
– Referência ao valor do recurso. Fraco. ex.
Bibliotecas de programação. Sempre disponíveis
localmente.
– Referência a um recurso de um dado tipo.
Mais fraco. ex. Referência a recursos locais
(monitores, impressoras etc)

06/04/11
 Migração de Código (cont)
● Modelos para migração de código
● Pode-se mudar a referência a recursos, porém, não
se pode mudar o tipo de vinculação processo-a-
recurso.
● Depende fortemente da possibilidade de mover o
recurso à máquina alvo.
● Complexidade varia de acordo com a relação do
recurso ao hardware. Recursos não “atachados” (ex.
Arquivos de dados associados ao programa) ou
recursos atachados (ex. Bases de dados locais, Web
sites completos). Recursos fixados estão
intimamente ligados ao hardware (ex. Dispositivos
locais).
06/04/11
 Migração de Código (cont)

06/04/11
 Migração de Código (cont)
● Migração em sistemas heterogêneos.
● Características heterogêneas de hardware e
software.
● Semelhante aos problemas de portabilidade.
● Problema atacado por meio de linguagens
interpretadas (ex. Java).
● Tentativas atuais pela redução de dependência de
linguagens de programação → tentativas de
migração de ambientes computacionais inteiros.
– Permite continuidade de operação caso uma máquina
precise ser desligada → congelar um ambiente, substituir
um nó, migrar o código e restaurar o ambiente.

06/04/11
 Migração de Código (cont)
● Migração em sistemas heterogêneos.
● Migração de máquinas virtuais.
● Como migrar memória?
1)Enviar páginas de memória à nova máquina
e reenviar aquelas que são modificadas
durante o processo de migração.
2)Parar a máquina virtual corrente; migrar
memória e iniciar a nova máquina virtual.
3)Deixar a nova máquina virtual recuperar as
novas páginas à medida que for necessário.
Cópia sob demanda.
06/04/11