Processos. Conteúdo Contextualização: Sistema Operacional Processos Ambientes de Execução ...

Post on 22-Apr-2015

110 views 0 download

Transcript of Processos. Conteúdo Contextualização: Sistema Operacional Processos Ambientes de Execução ...

Processos

Conteúdo

Contextualização: Sistema Operacional Processos

Ambientes de Execução

Threads Multi-thread X Multi-processos Servidores e Clientes multi-thread Virtualização em Sistemas Distribuídos

Contextualização: Sistema Operacional

Camadas de Software

Sistema OperacionalA função do sistema operacional é fornecer acesso e gerenciar

os recursos físicos (hardware) existentes em uma máquina: Processadores Memória Comunicação Storage

Contextualização: Sistema Operacional

Contextualização: Sistema Operacional

Funcionalidades Básicas de um Sistema Operacional:

Espera-se, de um Sistema Operacional, as seguintes características:Encapsulamento

Ocultar detalhes de sua implementação e prover apenas uma interface pública para acesso aos recursos.

ProteçãoImpedir que haja acesso indevido a recursos

ConcorrênciaProver acesso concorrente a recursos de forma transparente.

Contextualização: Sistema Operacional

Para prover concorrência, ou seja, a execução concorrente de diversos processos, um S.O. deve garantir que cada um deles tenha um ambiente de execução independente.

Esse isolamento é necessário para evitar que processos afetem de modo intencional ou malicioso o funcionamento uns dos outros, ainda que estejam em execução na mesma máquina.

Para isso, o S.O. fornece um “processador virtual” a cada um dos processos de maneira transparente.

Contextualização: Sistema Operacional

Mesmo sendo transparente, a concorrência tem um custo, o qual está associado a criação, gerenciamento e isolamento dos ambientes de execução dos processos.

Esse ambiente é composto por: Um espaço de endereçamento Recursos de comunicação (portas) Sincronização de Threads (concorrência) Recursos de alto nível (janelas, arquivos, etc.)

Processos: Ambientes de Execução

Cada vez que um processo é escalonado (recebe acesso ao processador), uma sequencia de passos deve ser executada (troca de contexto): Empacotar o processo em execução Transferí-lo para uma área de espera Buscar na área de espera o novo processo a executar Desempacotar o processo a executar

Parte do projeto de um S.O. é focada na eficiência com a qual faz a troca de contexto. Um grande número de processos concorrentes pode, facilmente, degradar a performance de todo o ambiente

Processos: Ambientes de Execução

Nas primeiras versões de S.O. (anos 70 e 80), cada ambiente de execução suportava apenas um processo, uma linha de execução.

Nos S.O. de gerações posteriores surgiu o conceito de Thread (linha de execução ou processos leves), cujo objetivo é minimizar o custo da troca de contexto.

Cada processo pode ter uma ou mais threads. Assim, nesses novos S.O., um ambiente de execução pode ter uma ou mais linhas de execução.

Threads

Threads

Processos multi-thread possuem uma ou mais threads (processos leves) criados à escolha do desenvolvedor.

Por compartilhar o ambiente de execução do processo que as contem, a criação e destruição de threads é mais barata e a troca de contexto no momento de sua execução é consideravelmente menor.

Threads de um mesmo processo são razoavelmente independentes entre si, mas compartilham o espaço de endereçamento e tem seu ciclo de vida ligado ao do processo que as contem.

Multi-threads X Multi-Processos

Aplicativos multi-thread apresentam diversas vantagens. Uma das mais significativas diz respeito a chamadas bloqueantes.

Quando um processo emite uma chamada bloqueante (exemplo: acesso a disco, conexão remota), todo o seu funcionamento fica suspenso até o retorno dessa chamada. Porém, se a mesma for feita em uma thread, apenas esta ficará bloqueada e o processo (e suas outras threads) poderão continuar a execução.

Multi-threads X Multi-Processos

Com o conhecimento sobre threads podemos avaliar os benefícios de uma implementação multi-thread sobre uma multi-processos: Criar uma nova thread em um processo é muito mais

barato que criar um novo processo Realizar a troca de contexto entre threads é muito mais

barato que realizá-la entre processos

Multi-threads X Multi-Processos

O compartilhamento de recursos entre Threads é mais simples que entre processos. O mesmo espaço de endereçamento permite a utilização conjunta de variáveis globais. Processos, por sua vez, tem que utilizar mecanismos de comunicação.

Threads são capazes de explorar ambientes com múltiplos processadores e, assim, aumentar ainda mais o paralelismo da aplicação.

Multi-threads X Multi-Processos

Porém, nem tudo são vantagens. Alguns cuidados devem ser tomados em ambientes multi-thread.

Por compartilharem o mesmo ambiente de execução, threads podem interferir no funcionamento umas das outras, o que exige um cuidado maior dos desenvolvedores para sincronização do seu funcionamento.

Multi-threads X Multi-Processos

A programação com threads (também chamada de programação concorrente) envolve alguns conceitos muito importantes: Condição de corrida Região crítica Variáveis de condição Semáforos

Tais conceitos são importantes para a correta implementação de aplicativos multi-thread e sua adequada sincronização.

Multi-threads X Multi-Processos

Em Sistemas Distribuídos, podemos aplicar o conceito Multi-thread tanto do lado cliente quanto do lado servidor.

Do lado cliente, é possível vislumbrar algumas vantagens: Redução da latência na comunicação, com a abertura de

diversos canais paralelos com o servidor. Evitar que chamadas bloqueantes congelem as respostas

ao usuário.

Exemplo: Browser web.

Servidores e Clientes Multi-thread

Porém, é do lado servidor que estão as maiores vantagens: Servidores com múltiplos processadores podem ter seu

paralelismo aumentado. Capacidade de atendimento de múltiplos clientes ao

mesmo tempo.

Para essa última vantagem, existem algumas arquiteturas que podem ser exploradas.

Servidores e Clientes Multi-thread

Arquitetura de Pool de Trabalhadores Ao ser iniciado o servidor, um pool fixo de threads é criado.

Essas threas podem ser de dois tipos:

Thread Despachante (Dispatcher Thread), responsável por receber as requisições e alocar uma thread operária para o atendimento.

Thread Operária (Worker Thread), responsável por atender a requisição. Podem emitir chamadas bloqueantes.

Servidores e Clientes Multi-thread

Arquitetura de Pool de Trabalhadores

Servidores e Clientes Multi-thread

Arquitetura de Thread por Pedido É derivada da arquitetura de pool de trabalhadores, porém

não é criada uma quantidade fixa de threads operárias. Essas são criadas a medida em que forem sendo necessárias (a pedido). Uma vez atendido o pedido, a thread operária é destruída, liberando os recursos alocados.

A vantagem óbvia é o melhor gerenciamento de recursos (evita-se o desperdício de manter alocada uma thread que não está em funcionamento). Porém é gerada uma sobrecarga de operação por ocasião da criação e destruição da thread.

Servidores e Clientes Multi-thread

Como já foi dito, durante a execução concorrente, é criado um “processador virtual” cujo objetivo é abstrair e tornar transparente, à thread ou processo, detalhes da troca de contexto.

Nos tempos atuais, esse conceito de virtualização foi estendido, e passou-se a virtualizar, não só o processador, como outros recursos e até mesmo o próprio S.O.

Existem vários modelos de virtualização atualmente:

Virtualização em Sistemas Distribuídos

Máquina Virtual de Processo Oferece um conjunto de funções abstratas que permitem

ao programa executar em ambientes virtualmente padronizados (exemplo: JVM).

Monitor de Máquina Virtual Uma camada de software acima do hardware e que o

protege, fornecendo um conjunto de instruções de hardware disponíveis aos diversos aplicativos em execução. (exemplo: VMWare).

Virtualização em Sistemas Distribuídos

Monitor de Máquina Virtual

Virtualização em Sistemas Distribuídos

Monitor de Máquina Virtual Uma das grandes vantagens no uso desse tipo de máquina

virtual é a diminuição da variedade real de máquinas e S.O. a serem utilizados. Um mesmo hardware/S.O. pode emular diversos hardwares/S.O. diferentes.

Além disso, outras vantagens também são facilmente observadas:

Facilidade de gerenciamento

Menos máquinas a gerenciar Aumento na portabilidade e flexibilidade

Facilidade na cópia e disponibilização de novos ambientes Aumento da confiabilidade e segurança

Isolamento total da aplicação e seu ambiente

Virtualização em Sistemas Distribuídos