2° Seminário de Avaliação da disciplina de Sistemas Operacionais(3ª Nota de Avaliação)

Critérios para avaliação:

O seminário será realizado em duplas escolhidas pelo professor desta disciplina. Terá nota de avaliação do conteúdo apresentado e entregue, também será avaliada a postura e clareza apresentada aos demais colegas de sala. Cada apresentação será filmada pelo professor responsável pela avaliação.

Grupo 01 – Visão GeralDiscentes: Fábio e Raquel

Grupo 02 – Conceitos de Hardware e SoftwareDiscentes: Ivanete e Renata

Grupo 03 – ConcorrênciaDiscentes: Bruna e Ana

Grupo 04 – Estrutura do Sistema OperacionalDiscentes: Ângela e Laura

Grupo 05 – ProcessosDiscentes: Thábata e Claudinéia

Grupo 06 – TheadDiscentes: Cleyton e Everton

Grupo 07 – Sincronização e Comunicação entre processosDiscentes: Adriana e Leidiany

1

Material de apoio para a realização do Segundo Seminário

Arquitetura de Sistemas Operacionais

Capítulo 1

VISÃO GERAL

• 1.1 Introdução:

Sistema Operacional nada mais é do que um conjunto de instruções executadas pelo processador. Sua função é controlar o funcionamento de um computador, gerenciando a utilização e o compartilhamento dos seus diversos recursos, como processadores, memórias e dispositivos de entrada e saída.

Sem SO, usuário deveria conhecer profundamente o computador para poder interagir com ele. Implicaria em trabalho lento e com possibilidade de erros.

A diferença entre um SO e aplicações convencionais é a maneira como as rotinas são executadas em função do tempo. O SO não tem início, meio e fim como as aplicações. Dependem de eventos assíncronos. Também pode ser chamado de Programa monitor, Executivo, supervisor ou Controlador.

• 1.2 Funções básicas:

- Facilidade de acesso aos recursos do sistema: Usuário não precisa se preocupar como é feita a comunicação com monitores, discos, impressoras, etc. O SO é uma interface entre o usuário e os recursos do sistema. Este conceito de ambiente simulado pelo SO também é chamado de Máquina Virtual (figura 1.1)

Compiladores, linkers, bibliotecas, depuradores e outras ferramentas são utilitários que facilitam a interação do usuário com o computador.

- Compartilhamento de recursos de forma organizada e protegida: Em sistemas onde diversos usuários compartilham recursos, é necessário controlar o uso concorrente destes recursos. Ex: Impressora, a impressão de um usuário não deve interferir na do outro. O SO controla estes acessos concorrentes. O compartilhamento também permite redução de custos, quando diversos usuários podem compartilhar periféricos como impressoras, discos, etc.

Dependendo do SO, podemos executar diversas tarefas ao mesmo tempo, como imprimir um documento e baixar um arquivo da Internet. E é o SO que controla estas atividades concorrentes.

prog rama do rese a na listas

mem ória d isco s

U C P

U suários

H ardw are

Sistema O peraciona lSistema O peracional

fitas

impressora s mo nitores

p rog rama s,sistem as eap lica tivos

usuários

Fig. 1.1 - Visão do Sistema Operacional

2

• 1.3 Máquina de níveis: Uma máquina, do ponto de vista do hardware, tem pouca utilidade. É através do software que esta máquina ganha utilidade (como armazenamento de dados, impressão, etc.) Uma operação efetuada por software pode ser implementada em hardware, bem como uma função executada pelo hardware pode ser simulada via software.

Os primeiros computadores eram programados através de fios ligados em painéis, criando grandes dificuldades e exigindo grande conhecimento da máquina.

A solução veio com o surgimento do SO, tornando a interação com o usuário mais simples, confiável e eficiente. (Figura 1.2)

H ardw a re

Sistem a O p eracion a l

u suá rios

Fig. 1.2 - Visão do computador pelo usuário

O computador pode ser visualizado como uma máquina de níveis ou máquina de camadas. Inicialmente vemos apenas dois níveis: hardware (nível 0) e SO (nível 1). Assim, o usuário pode enxergar a máquina como sendo apenas o SO, como se o hardware não existisse. Esta visão é chamada de máquina virtual.

Na verdade não existem apenas dois níveis, e sim tanto quantos forem necessários para adequar o usuário às suas diversas aplicações. A figura 1.3 representa a estrutura da maioria dos computadores, podendo conter mais ou menos camadas. A linguagem utilizada em cada um destes níveis é diferente, variando da mais elementar (baixo nível) à mais sofisticada (alto nível).

U ti li tá r io s

C ircu ito s Eletrô n icos

M icrop ro gra m a ção

Lin gua g em d e M á q uina

Sistem a O p era cio n a l

A p l ica tivo s

Fig. 1.3 - Máquina de Níveis

• 1.4 Tipos de Sistemas OperacionaisOs tipos de SOs e sua evolução estão diretamente relacionados com a evolução do hardware e das aplicações

por ele suportadas. A figura 1.4 sintetiza os diversos tipos de SOs, cujas características, vantagens e desvantagens serão abordadas em seguida.

3

Tipos deSistemas O peracionais

SistemasM onoprog ra máveis/

M onotarefa

Sistemasco m M últiplosProcessadores

SistemasM ultiprogram áveis/

M ultita refa

Fig. 1.4 - Tipos de Sistemas Operacionais

• 1.4.1 SOs monoprogramáveis/monotarefaOs primeiros SOs eram voltados para a execução de um único programa. Qualquer outra aplicação deveria

aguardar a aplicação concorrente terminar, para ser executada. Estes sistemas vieram a ser conhecidos como sistemas monoprogramáveis e se caracterizavam por permitir que o processador, a memória e os periféricos estejam exclusivamente dedicados à execução de um único programa.

Este tipo de SO está relacionado aos primeiros computadores da década de 60. Voltou a ser utilizado na década de 70 em estações de trabalho. Nos sistemas monotarefas, como também são conhecidos, todos recursos do sistema ficam exclusivamente dedicados a uma única tarefa.

Neste tipo de SO, o processador fica ocioso, por exemplo, quando espera a digitação de um dado. A memória é sub-utilizada caso não seja preenchida totalmente, e os periféricos, como discos e impressoras, estão dedicadas a um único usuário, nem sempre de forma integral (Figura 1.5).

M emóriaPrin cip a l

D ispo sitivo sde E/ S

U C P p rogram a /ta refa

Fig. 1.5 - Sistemas monoprogramáveis / monotarefa.

• 1.4.2 SOs multiprogramáveis / multitarefaOs SOs multiprogramáveis ou multitarefas são uma evolução do SO monoprogramáveis. Neste tipo de SO

os recursos computacionais são compartilhados entre diversos usuários e aplicações. Aqui várias aplicações compartilham esses mesmos recursos.

Aqui também, enquanto um programa espera por uma operação de leitura ou gravação em disco, outros programas podem estar sendo processados neste intervalo de tempo. Neste exemplo, observamos o compartilhamento da memória e do processador. O SO se preocupa em gerenciar o acesso concorrente a seus diversos recursos, de forma ordenada e protegida, entre os diversos programas (Figura 1.6).

4

M em óriaPrincip a l

D ispo sitivo sd e E/ S

U C P programa /ta refa

p rog ra ma /ta refa

p rog rama /ta refa

p rog rama /ta refa

p rog rama /ta refa

Fig. 1.6 – Sistemas multiprogramáveis / multitarefa

A vantagem deste tipo de SO é a redução do tempo de resposta das aplicações processadas no ambiente e de custos, a partir do compartilhamento de recursos do sistema entre diferentes aplicações. Apesar de mais eficientes, os SO multiprogramável tem implementação muito mais complexa.

Baseado no número de usuários que interagem com o sistema, o SO multiprogramável pode ser classificado como monousuário ou multiusuário. Os sistemas multiprogramáveis monousuário são encontrados em computadores pessoais e estações de trabalho, onde apenas um usuário interage com o sistema. Por exemplo, um usuário pode executar um editor de texto, ao mesmo tempo em que acessa a Internet e imprime um documento. Nos sistemas multiusuários, permite-se que diversos usuários conectarem-se ao sistema simultaneamente. A tabela 1.1 relaciona os tipos de sistemas em função do número de usuários.

Um usuário Dois ou mais usuáriosMonoprogramação / Monotarefa Monousuário Não disponívelMultiprogramação / Multitarefa Monousuário Multiusuário

Tabela 1.1 – Sistemas x Usuários

Os SO multiprogramáveis ou multitarefa, podem ainda ser classificados pela forma com que suas aplicações são gerenciadas, podendo ser divididos em sistemas batch, de tempo compartilhado ou de tempo real. Um SO pode suportar um ou mais destes tipos de processamento, dependendo de sua implementação (Figura 1.7).

5

Sistem asM ultiprog ram áveis/

ta refaM ulti

Sistem asBatch

Sistemas deTemp o Real

Sistemas deTemp o C om pa rtilha do

Fig. 1.7 – Tipos de sistemas multiprogramáveis / multitarefa.

• 1.4.2.1 Sistemas BatchOs sistemas batch foram os primeiros SOs multiprogramáveis implantados na década de 60. Os programas,

também chamados de jobs, eram executados através de cartões perfurados e armazenados em discos ou fitas, onde aguardavam para serem processados. Posteriormente, em função da disponibilidade de espaço na memória principal, os jobs eram executados, produzindo uma saída em disco ou fita.

Este tipo de processamento se caracteriza por não exigir a atenção do usuário com a aplicação. Todas entradas e saídas eram implementadas por algum tipo de memória secundaria, geralmente discos. Cálculos numéricos, compilações, ordenações e backups são exemplos de aplicações batch.

Estes sistemas podem ser bastante eficientes, por utilizar melhor o processador, entretanto, podem oferecer tempos de resposta longos. Atualmente não existem sistemas exclusivamente batch, sendo executados através de simulações quando necessário.

• 1.4.2.2 Sistemas de Tempo compartilhadoOs sistemas de tempo compartilhado (time-sharing), permitem que diversos programas sejam executados a

partir da divisão de tempo do processador em pequenos intervalos, chamados de fatia de tempo (time-slice). Caso o tempo disponibilizado não seja suficiente para a conclusão do programa, este é interrompido pelo SO e substituído por um outro, enquanto fica aguardando por uma nova fatia de tempo. Este ambiente dá a impressão que todo o sistema esta dedicado, exclusivamente, para cada usuário.

Geralmente, nestes sistemas a interação com o usuário se dá através de terminais de vídeo, teclado e mouse. Estes sistemas possuem uma linguagem de controle própria, permitindo ao usuário comunicar-se diretamente com o SO através de comandos. Assim, é possível por exemplo, a verificar arquivos armazenados num disco, ou cancelar a execução de um programa.

Devido a este tipo de interação, os sistemas de tempo compartilhado também são chamados de sistemas on-line. A maioria das aplicações comerciais atuais são processadas em sistemas de tempo compartilhado, pois oferecem

tempos baixos de resposta aos usuários e menores custos, em função da utilização compartilhada de diversos recursos.

• 1.4.2.3 Sistemas de Tempo RealOs sistemas de tempo real (real-time) são implementados de forma semelhante à dos sistemas de tempo

compartilhado. A diferença é o tempo de resposta exigido no processamento das aplicações.Nos sistemas de tempo compartilhado, o tempo de resposta pode variar sem comprometer as aplicações em

execução. Nos de tempo real, os tempos de resposta devem estar dentro de limites rígidos, que devem ser obedecidos, caso contrario poderão ocorrer sérios problemas.

No sistema de tempo real não existe a idéia de fatia de tempo. Um programa utiliza o processador o tempo que necessitar, ou ate que apareça outro mais prioritário. A prioridade de execução é definida pela própria aplicação e não pelo SO.

Estes sistemas podem ser encontrados em aplicações de controle de processos, como no monitoramento de refinarias de petróleo, controle de trafego aéreo, de usinas termoelétricas e nucleares, ou qualquer outra onde o tempo de resposta é fator fundamental.

• 1.4.3 Sistemas com Múltiplos ProcessadoresOs sistemas com múltiplos processadores caracterizam-se por possuir dois ou mais processadores interligados e

trabalhando em conjunto. Este tipo de sistema permite que vários programas sejam executados ao mesmo tempo, ou que um único programa seja subdividido em partes para serem executados simultaneamente em mais de um processador.

6

O uso de múltiplos processadores permitiu a criação de sistemas voltados para processamento científico (como a criação do mapa genético), no desenvolvimento aeroespacial, prospecção de petróleo, simulações, processamento de imagens, CAD e previsão do tempo. Pode-se afirmar que qualquer aplicação que faca uso intensivo do processador, será beneficiada pelo acréscimo de processadores ao sistema. A evolução destes sistemas se deve em grande parte, ao elevado custo de desenvolvimento de processadores de alto desempenho. É menos custoso interligar diversos processadores menores do que desenvolver um mais poderoso.

Além dos mesmos benefícios dos sistemas multiprogramáveis, o sistema com múltiplos processadores apresentam vantagens como:

Escalabilidade: é a possibilidade de se aumentar o poder computacional do sistema, adicionando-se novos processadores.

Disponibilidade: é a capacidade de manter o sistema em operação mesmo em caso de falha de uma ou mais maquinas. No caso de uma falha, as outras máquinas assumem suas funções de maneira transparente ao usuário, embora com menor poder de computação.

Balanceamento de carga: é a possibilidade de distribuir o processamento entre os diversos processadores, melhorando assim o desempenho do sistema como um todo.

Um fator-chave na criação de SOs com múltiplos processadores é a forma de comunicação entre eles e o grau de compartilhamento da memória e dos dispositivos de entrada e saída. Assim, podemos classificar os sistemas com múltiplos processadores em fortemente acoplados ou fracamente acoplados (Figura 1.8).

Fig. 1.8 – Tipos de Sistemas com múltiplos processadores

• 1.4.3.1 Sistemas fortemente acopladosNos sistemas fortemente acoplados (tightly coupled) vários processadores compartilham uma única memória

física (shared memory) e dispositivos de entrada e saída, sendo gerenciados por um único SO (Figura 1.9).

U C P U C PM emóriaPrin cipa l

D ispo sitivo sd e E/ S

D ispo sitivo sde E/ S

Fig 1.9 – Sistemas fortemente acoplados

Em virtude disso, este tipo de sistema também é chamado de multiprocessador.Os sistemas multiprocessadores dividem-se ainda em SMP (Symmetric MultiProcessor) e NUMA (Non-Uniform

Memory Access). Os sistemas SMP possuem tempo uniforme de acesso à memória principal pelos diversos processadores. Os

SistemasCom MúltiplosProcessadores

Sistemas FortementeAcoplados

SistemasFracamenteAcoplados

7

sistemas NUMA apresentam diversos conjuntos reunindo processadores e memória principal, sendo que cada conjunto é conectado aos outros através de uma rede de interconexão. O tempo de acesso à memória pelos processadores varia em função da sua localização física.

Nos sistemas SMP e NUMA todos processadores têm as mesmas funções. Inicialmente, os sistemas multiprocessadores limitavam-se a sistemas de grande porte. Com a evolução dos computadores pessoais, os sistemas multitarefa também evoluíram para permitir a existência de vários processadores no modelo simétrico. Atualmente, sistemas como Unix, Linux, Windows 200 e Windows XP implementam esta funcionalidade.

• 1.4.3.2 Sistemas fracamente acopladosOs sistemas fracamente acoplados (loosely coupled), caracterizam-se por possuir dois ou mais sistemas computacionais

conectados através de linhas de comunicação. Cada sistema funciona de forma independente, possuindo seu próprio sistema operacional e gerenciando seus próprios recursos, como processador, memória e dispositivos de entrada e saída (Figura 1.10).

U C P U C P

M em óriaPr in cip al

M em óriaPrin cip a l

D ispo sitivo sd e E/ S

link de co m un icaçã o

D ispo sitivo sde E/ S

Fig. 1.10 Sistemas fracamente acoplados

Em função destas características, os sistemas fracamente acoplados também são conhecidos como multicomputadores. Neste modelo, cada sistema computacional também pode ser formado por um ou mais processadores.

Até meados dos anos 80, as aplicações eram centralizadas em sistemas de grande porte, com um ou mais processadores. Nesta configuração, os usuários utilizavam terminais não-inteligentes conectados a linhas seriais dedicadas ou mesmo a linhas telefônicas públicas para comunicação interativa com estes sistemas. No modelo centralizado, os terminais não tem poder de processamento. A solicitação de uma tarefa ao sistema é feita através de linhas de comunicação.

A evolução dos computadores pessoais e também das telecomunicações, fez com que um novo modelo de computação surgisse, chamado de modelo de rede de computadores. Em uma rede existem dois ou mais sistemas independentes (hosts), interligados através de linhas de comunicação, oferecendo algum tipo de serviço aos demais. Assim, a informação deixa de ser centralizada em sistemas de grande porte e passa a ser distribuída pelos diversos sistemas da rede.

Baseando-se no grau de integração dos hosts da rede, dividimos os sistemas fracamente acoplados em sistemas operacionais de rede e sistemas distribuídos. A diferença básica entre eles é a capacidade do SO criar uma imagem única dos serviços disponibilizados pela rede.

Os sistemas operacionais de rede (SORs) permitem que um host compartilhe seus recursos como impressora ou disco, com os demais hosts da rede. Um exemplo disto são as redes locais.

Nos sistemas distribuídos o sistema operacional esconde os detalhes dos hosts individuais e passa a tratá-los como um conjunto único, como se fosse um sistema fortemente acoplado. Nos sistemas distribuídos, uma aplicação pode ser dividida em partes e cada parte pode ser executada por hosts diferentes da rede de computadores. Para os usuários e suas aplicações, é como se não existisse a rede de computadores, e sim um único sistema centralizado.

Outro exemplo de sistema distribuído são os clusters. Em um cluster existem dois ou mais servidores ligados, através de uma conexão de alto desempenho. O usuário não conhece os nomes dos membros do cluster e não sabe quantos são. Basta solicitar um serviço ao cluster para obtê-lo. Este tipo de sistema é usado atualmente em sistemas de banco de dados e Web, garantindo alta disponibilidade, escalabilidade e balanceamento de carga à solução.

8

Material de apoio para a realização do Segundo Seminário

Arquitetura de Sistemas Operacionais

Capítulo 2

CONCEITOS DE HARDWARE E SOFTWARE

2.1 Introdução:Neste capítulo serão apresentados brevemente, conceitos básicos de hardware e software, para compreensão

dos capítulos seguintes.

2.2 HardwareUm sistema computacional é um conjunto de circuitos eletrônicos interligados, formado por Processador ou

unidade central de processamento, memória principal e dispositivos de entrada/saída.

M emóriaPrin cipa l

D ispo sitivo sde E/ S

Processador / U C P

U n idade Lóg icae A ritm ética

Reg istra do res

U n id ad e deC ontro le

Fig. 2.1 Sistema Computacional

2.2.1 ProcessadorUm processador é composto por unidade de controle, unidade lógica e aritmética, e registradores. A unidade

de controle (UC) é responsável por gerenciar as atividades de todos os componentes do computador, como a gravação de dados em discos ou a busca de instruções na memória. A unidade lógica e aritmética (ULA), como o nome indica, é responsável pela realização de operações lógicas (testes e comparações) e aritméticas (somas e subtrações).

2.2.2 MemóriaA memória é composta por unidades de acesso chamadas células, sendo cada célula composta por um

determinado número de bits. Atualmente, a grande maioria dos computadores utiliza o byte (8 bits) como tamanho de célula.

Memórias voláteis precisam estar sempre energizadas para manter suas informações, o que não acontece com as não-voláteis.

9

célu la = 8 b its

ende

reço

s

0

2 -116

21

i n s t r u ç ã o o u d a d o

Fig. 2.2 – Memória principal com 64 Kbytes

2.2.3 Memória CacheA memória cache é uma memória volátil de alta velocidade, porém com pequena capacidade de

armazenamento. O tempo de acesso a um dado nela contido é muito menor que se o mesmo estivesse na memória principal. O propósito do uso da memória cache é minimizar a disparidade existente entre a velocidade com que o processador executa instruções e a velocidade com que dados são acessados na memória principal.

2.2.4 Memória Principal e SecundariaA memória principal é um dispositivo de armazenamento, em geral volátil, onde são armazenados instruções

e dados utilizados pelo processador durante a execução de programas. A memória secundária é um dispositivo não-volátil com maior capacidade de armazenamento, porém com menor velocidade de acesso aos seus dados armazenados.

ma iorca pa cidad e de

arm a zena m en to

ma ior custo evelocida ded e acesso

M em ó ria Secu nd ár ia

M emória C ache

M em ória Pr incip a l

Registrad ores

Fig. 2.3 – Relação entre dispositivos de armazenamento

10

2.2.5 Dispositivos e Entrada/SaídaOs dispositivos de entrada e saída podem ser divididos em duas categorias: os que são utilizados como

memória secundária e os que servem para a interface usuário-máquina. Os dispositivos utilizados como memória secundária (discos e fitas magnéticas) caracterizam-se por ter capacidade de armazenamento bastante superior ao da memória principal. Seu custo é relativamente baixo, porém o tempo de acesso à memória secundária é bem superior ao da memória principal. Outros dispositivos têm como finalidade a comunicação usuário-máquina, como teclados, monitores de vídeo, impressoras e plotters.

2.2.6 Barramentos ou BusBarramentos é o meio físico de comunicação entre as unidades funcionais de um sistema computacional. Os

barramentos processador-memória são de curta extensão e alta velocidade para que seja otimizada a transferência de informação entre processadores e memórias. Os barramentos de E/S possuem maior extensão, são mais lentos e permitem a conexão de diferentes dispositivos. O barramento de backplane tem a função de integrar os dois barramentos anteriores.

Barram ento processa do r- mem ória

Barra

men

to d

e E/

S

Barra

men

to d

e E/

SA daptado r A da ptado r

M em óriaPrincip a lU C P

Fig. 2.4 – Barramentos processador-memória e de E/S

11

Barramento processador-memória

Barra

men

to d

e E/

S

Barra

men

to d

e E/

S

A da ptado r A da ptado r

M emóriaPrincipa lU C P

A daptado r

Barra

men

tode

bac

kpla

ne

Fig. 2.5 – Barramento de Backplane

2.2.7 PipelineÉ uma técnica que permite ao processador executar múltiplas instruções paralelamente em estágios

diferentes.

U nida de de busca d ainstru çã o

P1 P4P3P2

A na lisad orda

instruçã o

U nida de de b usca dos

dado s

U nida de de execução da

instruçã o

Instr.1 Instr.2 Instr.3 Instr.4 Instr.5 Instr.6 Instr.7

Instr.1 Instr.2 Instr.3 Instr.4 Instr.5 Instr.6

Instr.1 Instr.2 Instr.3 Instr.4 Instr.5

Instr.1 Instr.2 Instr.3 Instr.4

P1

P2

P3

P4

tem poFig. 2.6 – Arquitetura pipeline com quatro estágios

12

Material de apoio para a realização do Segundo Seminário

Arquitetura de Sistemas Operacionais

Capítulo 3

CONCORRÊNCIA

3.1 Introdução:Os sistemas operacionais podem ser vistos como um conjunto de rotinas que executam concorrentemente de

forma ordenada. A possibilidade de o processador executar instruções em paralelo com operações de E/S permite que diversas tarefas sejam executadas concorrentemente. Concorrência é o princípio básico para projeto e implementação dos sistemas operacionais multiprogramáveis.

Os SOs monoprogramáveis eram limitados por seus recursos não serem utilizados de forma eficiente, limitando seu desempenho. Muitos recursos (alguns de alto custo), permaneciam ociosos por longos períodos de tempo.

O disperdício dos SOs monoprogramáveis pode ser representado na Figura 3.1a, pois enquanto uma leitura em disco é realizada, o processador permanece ocioso. O tempo de espera é relativamente longo, pois as operações de E/S são lentas comparadas às operações dos processadores.

2

(a ) Sistema M onoprogra máveltem po tem po

E/ S E/ S

U C P U C Plivre 11

1

(b ) Sistema M ultiprog ra m áve l

Fig. 3.1 – Sistema monoprogramável x sistema multiprogramável

A tabela 3.1 apresenta um exemplo de um programa que lê registros de um arquivo e executa, em média, 100 instruções por registro lido. Neste caso, o processador gasta cerca de 93% do tempo esperando o dispositivo de E/S concluir sua operação para então continuar o processamento.

Leitura de um registro 0,0015 sExecução de 100 instruções 0,0001 sTotal 0,0016 s% utilização da CPU (0,0001 / 0,0015) = 0,066 = 6,6 %

Tabela 3.1 Exemplo de utilização do sistema

A memória principal também é subutilizada se o programa não a ocupa totalmente, deixando áreas livres. Nos SOs multiprogramáveis, vários programas podem estar residentes em memória, concorrendo pela utilização do processador. Assim, o processador permanece menos tempo ocioso (Figura 3.1 b) e a memória é utilizada de forma mais eficiente, pois vários programas se revezam na utilização do processador.

A utilização concorrente do processador deve ser implementada de forma que, quando um programa perde o uso do processador, e depois retorna sua execução, deverá continuá-la na instrução seguinte àquela em que fora interrompido. Para o usuário, parece que nada aconteceu. Em sistemas de tempo compartilhado, existe a impressão de o sistema está inteiramente dedicado a ele.

Em sistema monoprogramáveis, temos periféricos (como impressoras e discos) parados por grandes períodos de tempo esperando ações de um único usuário.

Na tabela 3.2 temos as vantagens de um sistema multiprogramável, com um disco, um terminal e uma impressora. Nesta configuração, são executados três programas distintos (Prog1, Prog2 e Prog3).

Pela tabela, percebemos que Prog1 não realiza operações de E/S, ao contrário de Prog2 e Prog3.

13

Características Prog1 Prog2 Prog3Utilização do processador Alta Baixa BaixaOperações de E/S Poucas Muitas MuitasTempo de processamento 5 min 15 min 10 minMemória utilizada 50 Kb 100 Kb 80 KbUtilização de disco Não Não SimUtilização de terminal Não Sim NãoUtilização de impressora Não Não Sim

Tabela 3.2 – Características de execução do programas

Se fossem realizados num ambiente monoprogramável, seriam executados em seqüência, totalizando 30 minutos. Se fossem executados em ambiente multiprogramável, os ganhos são consideráveis, conforme mostra a tabela 3.3.

Características Monoprogramação MultiprogramaçãoUtilização do processador 17 % 33 %Utilização da memória 30 % 67 %Utilização de disco 33% 67 %Utilização de impressora 33 % 67%Tempo total de processamento 30 min. 15 min.Taxa de processamento 6 progr. / hora 12 progr. / hora

Tabela 3.3 – Comparação entre Mono e multiprogramação

A seguir, será apresentado técnicas de implementação da concorrência, essencial num sistema multiprogramável.

3.2 Interrupção e ExceçãoDurante a execução de um programa, eventos inesperados podem ocorrer, ocasionando um desvio forcado

em seu fluxo de execução. Estes tipos de eventos são conhecidos por interrupção ou exceção e podem ser conseqüência da sinalização de algum hardware externo ou da execução de instruções do próprio programa. A diferença entre interrupção e exceção e dada pelo tipo de evento ocorrido. Porém, nem sempre é feita esta distinção.

A interrupção permitiu a implementação da concorrência nos computadores. Com este mecanismo, o SO sincroniza a execução de todas suas rotinas e dos programas dos usuários, além de controlar dispositivos.

Uma interrupção é gerada por algum evento externo ao programam e independe da instrução que esta sendo executada. Um exemplo de interrupção ocorre quando um disco avisa ao processador que uma operação de leitura ou escrita está completa. Neste caso, o processador interrompe o programa e trata o término da operação.

Ao final da execução de cada instrução, a unidade de controle verifica a ocorrência de algum tipo de interrupção. Neste caso, o programa é desviado para uma rotina de tratamento de interrupção. Para o programa prosseguir posteriormente, as informações do programa executado são armazenadas em registradores no processador (Figura 3.2).

14

Fig. 3.2 – Mecanismos de interrupção e exceção

A tabela 3.4 descreve o mecanismo de interrupção, que pode ser realizado por hardware ou software.Para cada tipo de interrupção existe uma rotina de tratamento associada. A identificação do tipo de

interrupção é fundamental para determinar o endereço da rotina de tratamento.Existem dois métodos utilizados no tratamento das interrupções. O primeiro utiliza uma estrutura de dados

chamada de vetor de interrupção, que contem o endereço inicial de todas as rotinas de tratamento existentes, associadas a cada evento. Um segundo método utiliza um registrador de status que armazena o tipo do evento ocorrido. Neste método, só existe uma única rotina de tratamento, que no seu inicio testa o registrador para identificar o tipo de interrupção e tratá-la de maneira adequada.

Via Hardware 1. Um sinal de interrupção é gerado para o processador2. Após o termino da execução da instrução corrente, o processador identifica o

pedido de interrupção3. Os conteúdos dos registradores apropriados são salvos4. O processador identifica qual a rotina de tratamento que será executada e carrega

um registrador com o endereço inicial desta rotinaVia Software 5. A rotina de tratamento salva o conteúdo dos demais registradores na pilha de

controle de programas6. A rotina de tratamento é executada7. Após o termino da execução da rotina, os registradores são restaurados, retomando

a execução do programa interrompido

Tabela 3.4 – Mecanismo de interrupção

As interrupções são decorrentes de eventos assíncronos (não relacionados à instrução do programa). Estes eventos podem ser imprevisíveis e podem ocorrer múltiplas vezes. Isso possibilitaria a ocorrência de múltiplas interrupções simultâneas. Par evitar esta situação, é a rotina de tratamento inibir as demais interrupções. Assim, as interrupções posteriores seriam ignoradas durante a execução da rotina de tratamento, ou seja, não receberiam tratamento. Interrupções com estas características são chamadas de interrupções mascaráveis.

Alguns processadores não permitem que interrupções sejam desabilitadas. Neste caso, o processador precisa saber a ordem em que ocorreram as interrupções concorrentes. Para isso, as interrupções devem possuir prioridades, em função de sua importância. Normalmente, um dispositivo denominado controlador déb pedidos de interrupção, é o responsável por avaliar as interrupções geradas e suas prioridades.

Uma exceção é semelhante a uma interrupção, sendo a principal diferença, o motivo pelo qual o evento é gerado. A exceção é resultado direto da execução de uma instrução do próprio programa, como a divisão de um número por zero, ou a ocorrência de um “overflow” e operações aritméticas. Portanto, a exceção é gerada por um evento síncrono. Tais eventos são portanto previsíveis e só podem ocorrer um único de cada vez. Um programa com este tipo de evento que seja reexecutado a exceção ocorrera sempre na mesma instrução.

15

Assim como a interrupção, o programa interrompido é desviado para uma rotina de tratamento de exceção (Figura 3.2). O mecanismo de tratamento de exceções muitas vezes pode ser escrito pelo próprio programador. Assim, é possível evitar que um programa seja encerrado de ocorrer, por exemplo, um overflow.

3.3 Operações de Entrada/SaídaNos primeiros SOs, existiam instruções especiais para controlar periféricos, denominadas de instruções de

entrada/saída. Estas instruções continham detalhes de cada periférico, como por exemplo, na gravação de um bloco de dados em disco, deveria se especificar em qual trilha e setor ocorreria a gravação. Isto provocava uma forte dependência entre processador e os dispositivos de E/S.

O controlador de interface surgiu para permitir que o processador fique mais independente dos periféricos. Desta forma, o processador não se comunica mais diretamente com os dispositivos de E/S, mas sim através do controlador (Figura 3.3).

M em óriaPrin cip a lU C P

C ontro la do r

D ispo sitivo s de E/ S

Fig. 3.3 – Controlador de dispositivos de E/S

O controlador simplificou as instruções de E/S, pois o processador não necessitaria utilizar instruções detalhadas.

Com a utilização do controlador, existiam duas maneiras básicas pelas quais o processador gerenciava as operações de E/S:

- Na primeira, o processador sincroniza-se com o periférico para o inicio da troca de dados entre eles, e depois de iniciada a transferência, o sistema ficava permanentemente testando o estado dos periféricos para saber quando a operação de E/S terminaria. Este tipo de controle, chamado de E/S controlada por programa, mantinha o processador ocupado até o fim da operação de E/S (busy wait). Isto provocava um desperdício de tempo, pois o processador executa uma instrução muito mais rapidamente que a realização de uma operação de E/S.

- Na segunda, há uma evolução do modo anterior, onde uma vez iniciada a transferência de dados, o processador permanece livre para realizar outras tarefas. Neste caso, em determinados intervalos de tempo, o SO deve testar os dispositivos para saber do término da operação de E/S (polling). Esta técnica permitiu um tipo de paralelismo, sendo a base dos sistemas multiprogramáveis. O único inconveniente desta técnica, é que caso haja muitos periféricos, o processamento será interrompido freqüentemente.

Com o mecanismo de interrupção, as operações de E/S se tornaram mais eficientes, uma vez que o controlador interrompe o processador para avisar o fim de uma operação, ao invés do processador ficar constantemente verificando as operações pendentes (E/S controlada por interrupção). .

Esta última técnica é mais eficiente do que a controlada por programa, pois elimina a necessidade do processador esperar pelo término da operação, alem de permitir varias operações de E/S simultâneas.

Ainda existe um outro inconveniente neste processo. É o caso em que há uma grande quantidade de dados, onde as muitas intervenções do processador acabam por reduzir sua eficiência. Uma solução pensada para este problema, foi a técnica de transferência de dados chamada de DMA (Direct Memory Address).

A técnica DMA permite que um bloco de dados seja transferido entre a memória principal e um dispositivo de E/S, sem a intervenção do processador, exceto no inicio e no fim da transferência. Quando o sistema deseja ler ou

16

gravar um bloco de dados, o processador informa ao controlador sua localização, o dispositivo de E/S, a posição inicia da memória onde os dados serão lidos ou gravados e o tamanho do bloco. Com estas informações, o controlador realiza a transferência entre o periférico e a memória principal, e o processador será interrompido somente no final da operação. A área de memória utilizada pelo controlador na técnica de DMA é chamada de buffer de entrada/saída.

Na técnica de DMA, o controlador assume momentaneamente o controle do barramento. Neste caso, a utilização do barramento passa ser exclusiva do periférico, e o processador suspende temporariamente o acesso ao barramento. O processador pode nestas horas, realizar tarefas que não dependa, do barramento, como por exemplo, acesso à memória cache.

3.4 BufferingA técnica de buffering consiste na utilização de uma área na memória principal, denominada buffer, para a

transferência de dados entre os dispositivos de E/S e a memória. Esta técnica permite que em uma operação de leitura, o dado seja primeiramente transferido para o buffer, liberando imediatamente o dispositivo para uma nova leitura. Assim, enquanto o processador processa o dado localizado no buffer, o periférico realiza outra operação de leitura, simultaneamente. O mesmo mecanismo pode ser aplicado às gravações (Figura 3.4)

M emóriaPrincip al

U C P Bufferg ravaçã o gravaçã o

leitu ra leitu ra

C ontro lado r

Fig. 3.4 – Operações de E/S utilizando buffer

O objetivo desta técnica é manter, na maior parte do tempo, processador e dispositivos de E/S ocupados, pois minimiza o problema da disparidade da velocidade de processamento entre o processador e os dispositivos.

A unidade de transferência utilizada no buffering é o registro, que tem seu tamanho definido em função:- Da natureza do dispositivo. Por exemplo, uma linha gerada por uma impressora, ou um caractere de um

teclado.- Da aplicação, definido em arquivo.

Logicamente o buffer deve permitir armazenar diversos registros, de forma que hajam dados lidos e ainda não processados, ou processados mas ainda não gravados. Isto torna o processo bastante eficiente, pois é possível compatibilizar a diferença existente entre o tempo em que o processador executa instruções e o tempo em que o dispositivo de E/S realiza suas operações de leitura e gravação.

3.5 SpoolingA técnica de spooling (simultaneous peripheral operation on-line), introduzida no final dos anos 50, visa

aumentar o grau de concorrência e a eficiência dos SOs. Semelhante à técnica de buffering, a técnica de spooling utiliza uma área em disco como se fosse um grande

buffer. Neste caso, os dados podem ser lidos ou gravados em disco, enquanto programas são executados concorrentemente.

Esta técnica esta presente na maioria dos SOs, utilizada no gerenciamento de impressão. No momento em que um comando de impressão é executado, as informações a serem impressas são gravadas antes em um arquivo em disco, conhecido como arquivo de spool, liberando o programa para outras atividades. Posteriormente, o SO se encarrega de direcionar o conteúdo do arquivo de spool para a impressora (Figura 3.5).

Program a ImpressoraA rqu ivode Spoo l

Sistem a O peracion a lSistem a O peraciona l

Fig. 3.5 – Técnica de Spooling

17

Esta técnica desvincula o programa do dispositivo impressor, impedindo que um programa reserve a impressora para uso exclusivo. O SO gerencia a seqüência de impressões solicitadas pelos programas, seguindo critérios de segurança e de uso eficiente das impressoras.

3.6 ReentrânciaEm sistemas multiprogramáveis, vários usuários podem utilizar o mesmo aplicativo simultaneamente. Se

cada um deles trouxesse o programa para uma área de memória, haveria desperdício de recursos (espaço em memória).

Chamamos de reentrância, a capacidade de um código executável (código reentrante) ser compartilhado entre vários usuários, exigindo apenas uma cópia do programa em memória. Esta técnica permite que cada usuário possa estar em um ponto diferente do código reentrante, manipulando dados próprios e exclusivos de cada usuário (Figura 3.6).

M emória Principa l

código reentrante

á rea de d ados do u su á rio A

usu á rio A usuário C

usuá rio B usuário D

á rea de dad os d o u suá rio B

á rea de d ados do u su á rio C

á rea de d ados do u su á rio D

Fig. 3.6 – Reentrância

3.7 Proteção do SistemaA complexidade de um sistema multiprogramável resulta em alguns problemas de proteção. Considerando

que diversos usuários compartilham os mesmos recursos, como memória e processador, deve existir uma preocupação com a confiabilidade e integridade dos dados e programas dos usuários, alem do próprio SO.

Como vários programas ocupam a memória simultaneamente, cada usuário possui uma área reservada onde seus dados e código são armazenados. O SO deve preservar estas informações. Caso um programa tente acessar uma posição de memória fora de sua área, um erro indicando a violação deve ocorrer.

Semelhante ao compartilhamento de memória, um disco armazena arquivos de diferentes usuários. Novamente o SO deve garantir a integridade e confidencialidade dos dados de cada usuário. O compartilhamento de arquivos em disco permite que dois ou mais usuários acessem um mesmo arquivo simultaneamente pelo SO.

No sistema multiprogramável, diversos programas compartilham o processador. Portanto, deve ser tarefa do SO também, o controle da utilização do processador, evitando que algum programa monopolize seu uso.

Assim, o SO deve implementar diversos mecanismos de proteção que controlem o acesso concorrente aos diversos recursos do sistema. Estes mecanismos serão abordados em capítulos posteriores.

18

Material de apoio para a realização do Segundo Seminário

Arquitetura de Sistemas Operacionais

Capítulo 4

ESTRUTURA DO SISTEMA OPERACIONAL

4.1 Introdução:O Sistema Operacional é formado por um conjunto de rotinas que oferecem serviços aos usuários, às suas

aplicações, e ao próprio sistema. Este conjunto de rotinas é denominado núcleo do sistema ou kernel.Não confundir o núcleo do sistema com aplicações, utilitários ou interpretadores de comando, que

acompanham o SO. (Figura 4.1). As aplicações são utilizadas pelos usuários e não mostram os detalhes da interação com o sistema. Os utilitários, como compiladores e editores de texto, e os interpretadores de comando, permitem aos usuários, administradores e desenvolvedores, uma interação amigável com o sistema.

U tili tá rio s

H ardw a re

N úcleo doSistem a O peraciona l

A p licativos

Fig. 4.1 – Sistema Computacional

Uma das dificuldades de se compreender o funcionamento de um SO, é devido ao fato que ele não possui um início, um meio e um fim, como outras aplicações. Suas ações dependem de eventos que não ocorrem em uma ordem pré-definida. Muitos eventos estão relacionados ao hardware e ao próprio sistema.

As principais funções do núcleo na maioria dos SOs estão listadas a seguir: Tratamento de interrupções e exceções; Criação e eliminação de processos e threads; Sincronização e comunicação entre processos e threads; Escalonamento e controle dos processos e threads; Gerência de memória; Gerência do sistema de arquivos; Gerência de dispositivos de E/S; Suporte a redes locais e distribuídas; Contabilização do uso do sistema; Auditoria e segurança do sistema.

A forma como o código do sistema é organizado e o relacionamento com seus diversos componentes varia de acordo com o projeto do SO.

4.2 System CallsUma grande preocupação no projeto de um SO, é quanto a sua integridade, ou seja, a proteção do núcleo do

sistema contra possíveis acessos não-autorizados. 19

As system calls (chamadas ao sistema) podem ser entendidas como uma porta de entrada para o acesso ao núcleo do sistema e seus serviços. Quando um usuário ou aplicação necessitar de algum serviço do sistema, é feita uma chamada a uma de suas rotinas através de uma system call. O termo system call é típico de ambientes Unix, no ambiente Windows é conhecida como API (Application Program Inteface).

Para cada serviço disponível existe uma system call associada. Cada SO tem seu próprio conjunto de chamadas diferentes (Figura 4.2). Isto explica o fato de uma aplicação desenvolvida para um SO, não pode ser executada em outro.

System C a ll

A pl icaçã o Bib lio teca H a rdw are

N úcleo doSistem a O pera cion a l

N úcleo doSistem a O peracio n a l

Fig. 4.2 System call

Algumas tentativas foram feitas para padronizar uma biblioteca de chamadas. O padrão POSIX (Portable Operating System Interface for Unix), por exemplo, foi estabelecido com a intenção de unificar as diversas versões do Unix existentes.

Através de parâmetros fornecidos nas system calls, a solicitação é processada e uma resposta é retornada à aplicação, junto com um status indicando erro ou não. A ativação e comunicação entre programas e o SO, é semelhante a uma sub-rotina de um programa.

As system calls podem ser divididas em grupos de funções (Tabela 4.1)Muitos usuários e mesmo programadores não imaginam os detalhes que envolvem um simples comando de

leitura de um arquivo, quando se utiliza uma linguagem de programação de alto nível. O compilador converte este comando de alto nível para uma system call específica, que quando executada, verifica a ocorrência de erros e retorna os dados ao programa, de forma transparente ao usuário.

Funções System Calls

Gerência de processos e threads

Gerência de memória

Gerência de sistema de arquivos

Gerência de dispositivos

Criação e eliminação de processos e threadsAlteração das características de processos e threadsSincronização e comunicação entre processos e threadsObtenção de informação sobre processos e threads

Alocação e desalocação de memória

Criação e eliminação de arquivos e diretóriosAlteração das características de arquivos e diretóriosAbrir e fechar arquivosObtenção de informações sobre arquivos e diretórios

Alocação e desalocação de dispositivosOperações de entrada/saída em dispositivosObtenção de informações sobre dispositivos

Tabela 4.1 – Funções das system calls

4.3 Modos de AcessoAlgumas instruções não podem ser colocadas diretamente à disposição das aplicações, pois sua utilização

indevida poderia ocasionar problemas à integridade do sistema. Por exemplo, uma aplicação que atualize um arquivo em disco. O programa por si só, não pode especificar diretamente as instruções que acessam seus dados no disco. Como o disco é um recurso compartilhado, quem gerencia exclusivamente sua utilização é o SO. Assim se evita que a aplicação acesse qualquer parte do disco indiscriminadamente, o que poderia comprometer a segurança e integridade do sistema de arquivos.

Portanto, fica claro que certas instruções só devem ser executadas pelo SO ou sob sua supervisão, impedindo assim riscos de segurança e integridade. As instruções que possuem o poder de comprometer o sistema são conhecidas como instruções privilegiadas, enquanto que as não-privilegiadas não oferecem estes riscos.

20

Para que uma aplicação não execute uma instrução privilegiada, deve ser implementado no processador um mecanismo de proteção, conhecido como modos de acesso. São basicamente dois os modos de acesso implementados pelo processador. O primeiro é o modo usuário, onde a aplicação só poderá executar instruções não-privilegiadas, tendo acesso a um numero reduzido de instruções. O segundo modo é o modo kernel ou supervisor, onde a aplicação tem acesso ao conjunto total de instruções do processador.

O modo de acesso de uma aplicação é determinado por um registrador de status do processador (chamado de PSW), Dependendo do conteúdo deste registrador, o hardware verifica se a instrução pode ou não ser executada pela aplicação.

Apenas o SO deve ter acesso às instruções privilegiadas. Portanto, se uma aplicação necessitar executar uma instrução privilegiada, deve solicitar sua execução através de uma system call. A system call altera o status do PSW para modo kernel, e ao termino de sua execução retorna ao modo usuário (Figura 4.3). Caso uma aplicação tente executar uma instrução privilegiada em modo usuário, o processador sinaliza um erro, uma exceção será gerada e o programa será interrompido.

No mesmo exemplo do acesso ao disco, para o programa atualizar um arquivo, a aplicação deve solicitar a operação ao SO por meio de uma system call, que altera o modo de acesso para kernel. Após efetuar a atualização, retorna-se ao modo usuário.

O mecanismo de modos de acesso também é uma boa forma de proteger o próprio núcleo do sistema residente em memória. Por exemplo, se uma aplicação tivesse acesso à área de memória onde está o SO, um programador mal-intencionado ou um erro de programação poderia ter acessar esta área e acabar danificando o sistema. Com os modos de acesso, apenas em modo kernel poderia se efetuar tal tarefa.

Fig. 4.3 – Chamada a uma rotina do sistema

4.4 Arquitetura MonolíticaA arquitetura monolítica pode ser comparada com uma aplicação formada por vários módulos que são

compilados separadamente e depois linkados, formando um grande e único programa executável, onde os módulos podem interagir livremente. Os primeiros SOs baseavam-se neste modelo, tornando seu desenvolvimento e sua manutenção bastante difíceis. A estrutura monolítica apresenta simplicidade e bom desempenho, por isso foi usada no projeto do MS-DOS e nos primeiros sistemas Unix (Figura 4.4).

21

M odo kernel

ap licação ap lica ção

M odo u suá rio

System ca ll

H ardw are

Fig. 4.4 – Arquitetura monolítica

4.5 Arquitetura de CamadasOs sistemas operacionais tornaram-se mais complexos e maiores em tamanho, por isso, novas técnicas de

programação estruturada e modular foram incorporadas ao seu projeto. Na arquitetura de camadas, o sistema é dividido em níveis sobrepostos. Cada camada oferece um conjunto de funções que podem ser utilizadas apenas pelas camadas superiores.

O primeiro SO a usar este conceito, surgiu em 1968 na Holanda e utilizava seis camadas. Posteriormente, sistemas como MULTICS e OpenVMS também implementaram o conceito de camadas, agora sob forma concêntrica (Figura 4.5). Neste formato, as camadas mais internas são mais privilegiadas que as externas.

22

Fig. 4.5 – Arquitetura em camadas do OpenVMS

A vantagem da arquitetura em camadas é isolar as funções do SO, facilitando sua manutenção e depuração, alem de criar uma hierarquia de níveis de modos de acesso, protegendo as camadas mais internas. Porém, seu desempenho é inferior ao modelo monolítico. Cada nova camada implica uma mudança no modo de acesso. Por exemplo, no caso do OpenVMS, para ter acesso aos serviços oferecidos pelo kernel é preciso passar por três camadas ou três mudanças no modo de acesso.

Atualmente, a maioria dos SOs utiliza o modelo de duas camadas, onde existem módulos de acesso usuário (não-privilegiado) e kernel (privilegiado). A maioria das versões do Unix e do Windows 2000 baseiam-se neste modelo.

4.6 – Máquina VirtualUm sistema computacional é formado por níveis, onde a camada de nível mais baixo é o hardware. Acima dele,

encontramos o SO, que oferece suporte para as aplicações, como visto na Figura 4.1. O modelo de máquina virtual, ou virtual machine (VM), cria um nível intermediário entre o hardware e o SO, denominado gerência de máquinas virtuais (Figura 4.6). Este nível cria diversas maquinas virtuais independentes, onde cada uma oferece uma cópia virtual do hardware, incluindo os modos de acesso, interrupções, dispositivos de E/S, etc.

Como cada VM é independente das demais, é possível que cada uma tenha seu próprio SO e que seus usuários executem suas aplicações como se todo o computador estivesse dedicado a cada um deles, Na década de 60, a IBM implantou este modelo no VM/370, permitindo aplicações batch, desenvolvidas em antigos sistemas OS/360 e aplicações de tempo compartilhado pudessem conviver na mesma máquina de forma transparente aos usuários e aplicações.

Além de permitir SOs diferentes no mesmo computador, este modelo cria o isolamento total entre cada VM, oferecendo grande segurança para cada uma delas. Por exemplo, se uma VM executar uma aplicação que comprometa o funcionamento de seu SO, as demais VMs não sofrerão qualquer problema. A maior desvantagem desta arquitetura é sua complexidade, que necessita compartilhar e gerenciar os recursos de hardware entre as diversas VMs.

23

A p 1

VM 1

VM 2

VM n

G erência de M á quinas V irtuais

H ardw are

SO 1

H V 1

A p 2

SO 2

H V 2

A p n

SO n

H V n

Fig. 4.6 – Máquina Virtual

Temos outro exemplo desta arquitetura, na linguagem Java, criada pela Sun Microsystems. Para executar um programa em Java, é necessário uma máquina virtual Java (ou Java Virtual Machine – JVM). Qualquer SO pode suportar uma aplicação Java, desde que exista uma JVM desenvolvida para ele. Assim, a aplicação não precisa ser compilada para cada sistema, tornando-se independente do hardware e SO utilizado (Figura 4.7).

M áqu ina V irtu a l J ava

H ardw a re

Sistema O peraciona l

A plicaçã o

Fig. 4.7 – Máquina Virtual Java

4.7 Arquitetura MicrokernelUma tendência nos SOs modernos é tornar o núcleo do sistema operacional o menor e mais simples possível.

Para implementar esta idéia, os serviços do sistema são disponibilizados através de processos, onde cada um é responsável por oferecer um conjunto específico de funções, como gerência de arquivos, de processos, de memória e escalonamento.

Se uma aplicação desejar algum serviço, é realizada uma solicitação ao processo responsável. Neste caso, a aplicação é chamada de cliente e o processo que responde é chamado de servidor. A solicitação é feita enviando-se uma mensagem ao servidor, que responde com outra mensagem. A principal função do núcleo é realizar esta comunicação entre cliente e servidor (Figura 4.8).

24

M odo kernelM odo usuá rio

M icrokernel

mensa

gem

mensagem

H ardw are

Fig. 4.8 – Arquitetura Microkernel

Este conceito de Arquitetura Microkernel surgiu na década de 80, com o sistema operacional Mach. O núcleo do Mach oferece basicamente quatro serviços: gerência de processos, gerência de memória, comunicação por troca de mensagens e operações de E/S, todos em modo usuário.

A utilização deste modelo permite que os servidores executem em modo usuário, ou seja, não tenham acesso direto a certos componentes do sistema. Apenas o núcleo do SO, responsável pela comunicação entre clientes e servidores, executa no modo kernel. Assim, se um erro ocorrer em um servidor, este poderá parar, mas o sistema não ficará inteiramente comprometido, aumentando sua disponibilidade (tempo em que está acessível).

Como os servidores se comunicam através de troca de mensagens, não importa se os clientes e servidores são processados em um sistema com um processador, com múltiplos processadores (fortemente acoplados) ou ainda em um ambiente de sistema distribuído (fracamente acoplados). A implementação de sistemas microkernel em ambientes distribuídos permite que um cliente solicite um serviço e a resposta seja processada remotamente. Isso permite acrescentar novos servidores à medida que aumenta o numero de clientes, conferindo uma grande escalabilidade ao SO.

Outra vantagem é que a arquitetura microkernel permite isolar as funções do sistema operacional por diversos processos servidores pequenos e dedicados a serviços específicos, tornado o núcleo menor, mais fácil de depurar e, conseqüentemente, aumentando sua confiabilidade. Na arquitetura microkernel, o sistema operacional passa a ser de mais fácil manutenção, flexível e de maior portabilidade. Apesar de todas as vantagens deste modelo, sua implementação, na prática, é muito difícil. Primeiro existe o problema de desempenho, devido à necessidade de mudança de modo de acesso a cada comunicação entre clientes e servidores. Outro problema é que certas funções do sistema operacional exigem acesso direto ao hardware, como operações de E/S.

Na verdade, o que se implanta normalmente é a combinação do modelo de camadas com a arquitetura de microkernel. O núcleo do sistema, além de ser responsável pela comunicação entre cliente e servidor, passa a incorporar outras funções críticas, como escalonamento, tratamento de interrupções e gerência de dispositivos.

4.8 Projeto do SistemaO projeto de um SO é bastante complexo e deve atender inúmeros requisitos, algumas vezes conflitantes,

como confiabilidade, portabilidade e facilidade de manutenção. O projeto irá depender muito da arquitetura do hardware utilizado e do tipo de sistema que se deseja construir: batch, tempo compartilhado, mono usuário ou multiusuário, tempo real, etc.

Os primeiros SOs foram desenvolvidos em assembly e seus códigos possuíam cerca de um milhão de instruções (ex.: IBM OS/360). Com a evolução dos SOs e conseqüentemente o aumento do numero de linhas de

25

código (cerca de 20 milhões no sistema MULTICS), novas técnicas de programação modular foram incorporadas ao projeto, além do uso de linguagens de alto nível, como PL/1 e Algol. Nos SOs atuais, o número de linhas de código chega perto dos 40 milhões (Windows 2000), sendo escrito grande parte em linguagem C/C++, utilizando em alguns casos, programação orientada a objetos.

Existe uma série de vantagens na utilização de programação por objetos no projeto e na implementação de sistemas operacionais. Os principais benefícios são:

- melhoria na organização das funções e recursos do sistema;- redução no tempo de desenvolvimento;- maior facilidade na manutenção e extensão do sistema e- facilidade de implementação do modelo de computação distribuída.

Além disso, o uso de uma linguagem de alto nível permite maior portabilidade, ou seja, o SO pode ser adaptado para outra arquitetura de hardware. Por outro lado, o uso de linguagens de alto nível em relação à programação assembly, apresenta perda de desempenho. Por isso, partes críticas do sistema, como device drivers, o escalonador e as rotinas de tratamento de interrupções, são ainda desenvolvidas em assembly.

Um princípio fundamental no projeto de SOs é a separação no projeto do sistema das políticas e dos mecanismos. A política define o que deve ser feito, e o mecanismo define como implementar esta política.

26

Material de apoio para a realização do Segundo Seminário

Arquitetura de Sistemas Operacionais

Capítulo 5

PROCESSO

5.1 IntroduçãoO processo é a base para implantação de um SO multiprogramável. O processador executa instruções, sem

distinguir qual programa se encontra em execução. A gerência de um ambiente multiprogramável é uma função exclusiva do SO, que deve controlar a execução dos diversos programas e o uso concorrente do processador. Assim, um programa deve estar associado a um processo.

O termo processo surgiu após os SOs multiprogramáveis, sendo utilizado no lugar de tarefa ou job, por grande parte da literatura técnica.

O SO deve controlar os processos. Através dos processos, um programa pode alocar recursos, compartilhar dados, trocar informações e sincronizar sua execução. Nos SOs multiprogramáveis, os processos são executados concorrentemente, compartilhando, entre outros recursos, o uso do processador, da memória e dos dispositivos de E/S. Em sistemas multiprocessados, além da concorrência de processos pelo uso do processador, existe também a execução simultânea de processos nos diferentes processadores.

Aqui abordaremos os principais conceitos relacionados aos processos.

5.2 Estrutura do ProcessoInicialmente, pode-se entender um processo, como um programa em execução, porém, com um conceito

mais abrangente. Imaginemos como os SOs multiprogramáveis atendem os diversos usuários e ainda mantém informações a respeito dos vários programas executados ao mesmo tempo.

Em um sistema multiusuário, cada usuário é associado a um processo. Ao executar um programa, o usuário tem a impressão de possuir o processador e demais recursos exclusivamente para si. Na verdade, o processador executa o programa de um usuário durante um intervalo de tempo, e no instante seguinte poderá estar executando um outro programa de outro usuário.

Para que esta troca ocorra sem traumas, é necessário que as informações do programa interrompido sejam guardadas, para que no seu retorno, nada seja perdido. Todas informações importantes e necessárias à execução de um programa fazem parte de um processo.

Um processo também pode ser definido como o ambiente em que o programa é executado. Este ambiente possui informações sobre a execução, de quanto de recursos do sistema cada programa pode utilizar, como espaço de memória, tempo do processador e área em disco.

A execução de um mesmo programa pode variar dependendo do processo no qual ele é executado, ou seja, em função dos recursos disponíveis. A falta de recursos pode impedir um programa de ser executado com sucesso. Por exemplo, caso um programa precise utilizar uma área em disco superior ao seu limite, o SO deve interromper sua execução por falta de recursos.

Um processo é formado por três partes, denominadas contexto de hardware, contexto de software e espaço de endereçamento, que juntas mantêm todas informações necessárias à execução de um programa (Figura 5.1).

27

Pro gram a

C o n texto d eSo ftw a re

C o n texto d eH a rdw are

Esp aço deEn dereça m en to

Fig. 5.1 – Estrutura do processo

5.2.1 Contexto de hardwareO contexto de hardware guarda o conteúdo dos registradores do processador. Quando um processo está em

execução, o seu contexto de hardware está armazenado nos registradores do processador. Quando o processo perde a utilização da CPU, o sistema salva as informações no contexto de hardware do processo.

O contexto de hardware é fundamental nos sistemas multiprogramáveis, onde o revezamento da CPU permite que os processos sejam interrompidos e posteriormente restaurados. A troca de um processo por outro no processador, executada pelo SO, é chamada de mudança de contexto, e consiste em salvar o conteúdo dos registradores do processo que esta saindo e carregá-los com os valores referentes ao do novo processo que será executado (Figura 5.2).

5.2.2 Contexto de softwareNo contexto de software são especificadas as características e limites dos recursos que podem ser alocados

pelo processo, como o numero Maximo de arquivos abertos simultaneamente, prioridade de execução e tamanho do buffer dos dispositivos de E/S. Muitas destas características são determinadas no momento da criação do processo, enquanto outras podem ser alteradas posteriormente.

A maior parte das informações do contexto de software do processo são provenientes de um arquivo do SO, conhecido como arquivo de contas. Neste arquivo, gerenciado pelo SO, são especificados os limites dos recursos que cada processo pode alocar. Outras informações presentes no contexto de software são geradas dinamicamente ao longo da execução dos processos.

28

C arrega reg istrado res doProcesso B

C arrega reg istrado res doProcesso A

Sistem a O peraciona l

Salva reg istradores doProcesso A

executando

executando

executando

Salva reg istradores doProcesso B

Processo A Processo B

Fig. 5.2 – Mudança de contexto

O contexto de software é composto por três grupos de informações sobre o respectivo processo: identificação, quotas e privilégios.

IdentificaçãoCada processo criado pelo sistema recebe uma identificação única (chamada de PID – Process IDentification), representada por um número e em alguns casos também através de um nome. É através do PID que o SO e outros processos podem fazer referência a qualquer processo existente, consultando e até alterando suas características.O processo possui também a identificação do usuário ou do processo que o criou (owner). Cada usuário possui uma identificação também única no sistema (representada pelo UID – User Identification), que é atribuída ao processo no momento de sua criação. A UID permite implementar modelos de segurança, onde apenas os objetos (processos, arquivos, áreas de memória, etc) que possuam um UID autorizado, podem ser acessados.

QuotasAs quotas são os limites de cada recurso do sistema que um processo pode alocar. Caso uma quota seja insuficiente, o processo poderá ser executado lentamente, interrompido ou mesmo não ser executado. Alguns exemplos de quotas presentes nos SOs modernos:- número máximo de arquivos abertos simultaneamente;- tamanho máximo de memória principal e secundaria que o processo pode alocar;- número máximo de operações de E/S pendentes;- tamanho máximo do buffer para operações de E/S;- numero máximo de processos, subprocessos e threads que podem ser criados.

PrivilégiosOs privilégios ou direitos definem as ações que um processo pode fazer em ralação a ele mesmo, aos demais processos e ao SO.

29

Privilégios que afetam o próprio processo permitem que suas características possam ser alteradas, como prioridade de execução, limites alocados na memória principal e secundaria, etc. Já os privilégios que afetam os demais processos permitem, alem da alteração de suas próprias características, alterar as de outros processos.Privilégios que afetam o sistema são mais amplos e poderosos, pois estão relacionados à gerência do ambiente, como a desativação do sistema, alteração de regras de segurança, criação de outros processos privilegiados, modificação de parâmetros de configuração do sistema, entre outros. A maioria dos SOs possui uma conta de acesso com todos privilégios disponíveis, afim de o administrador gerenciar o SO. Nos sistemas Unix, existe a conta “root”, no Windows 2000 a conta “administrador” e no Open VMS a conta “system”.

5.2.3 Espaço de endereçamentoO espaço de endereçamento é a área de memória pertencente ao processo onde as instruções e dados do

programa são armazenados para execução. Cada processo possui seu próprio espaço de endereçamento, que deve ser devidamente protegido do acesso dos demais processos. A Figura 5.3 ilustra as características da estrutura de um processo.

Program a

C on texto d eSo ftw are

p riorida de deexecuçã o reg istra dor PC

d a ta / horad e cria çã o

tem po d ep roce ssa dor

reg istra dor SP

q uota s

priv ilég ios

en dereços d e m em óriap rincipa l a loca dos

reg istra dorde sta tus

own er (U ID )PID

no m ereg istra dores

g era is

C ontexto deH ardw are

Espaço d eEndereça men to

Fig. 5.3 – Características da estrutura de um processo

5.2.4 Bloco de controle do processo O processo é implementado pelo SO através de uma estrutura de dados chamada Bloco de controle de

processos (Process Control Block – PCB). A partir do PCB, o SO mantém todas as informações sobre o contexto de hardware, contexto de software e espaço de endereçamento de cada processo (Fig. 5.4).

30

........

ponteiros

Esta do do processo

Registrad ores

N om e do processoPr io r id ad e d o p rocesso

Lim ites de m em ó riaLista d e a rqu ivos a bertos

Fig. 5.4 – Bloco de controle do processo (PCB)

5.3 Estados do ProcessoEm um estado multiprogramável, um processo não deve alocar o processador com exclusividade, de forma

que possa ser compartilhado. Os processos passam por diferentes estados ao longo de seu processamento, em função de eventos gerados pelo SO ou pelo próprio processo. Um processo ativo pode encontra-se em três estados diferentes:

Execução (running) – Um processo é dito no estado de execução quando está sendo processado pela CPU. Em sistemas com apenas um processador, somente um processo estará sendo executado em um dado instante. Os processos se alternam na utilização do processador, seguindo uma política estabelecida pelo SO. Em sistemas com multi-processadores, existe a possibilidade de mais de um processo ser executado ao mesmo tempo, como também é possível um mesmo processo ser executado simultaneamente em mais de um processador (processamento paralelo).

Pronto (ready) – Um processo está no estado de pronto quando aguarda apenas para ser executado.

O SO que determina a ordem e o critério pelos quais os processos neste estado devem utilizar o processador. Este mecanismo é conhecido como escalonamento.Em geral, existem vários processos no estado de pronto, organizados em listas encadeadas. Os processos devem estar ordenados pela sua importância (Figura 5.5).

........

........

........

........

........

Lista deprocessosem estadode pronto

PCB#5

PCB#9

PCB#1

PCB#2 PCB#4

Lista deprocessosem estadode espera

Fig. 5.5 – Lista de PCBs nos estados de pronto e espera.

31

Espera (wait) – Um processo no estado de espera aguarda por algum evento externo ou por algum recurso para prosseguir seu processamento. Por exemplo, o término de uma operação de E/S ou a espera de uma data ou hora para continuar sua execução. Em alguns SOs, este estado também pode ser chamado de bloqueado (blocked).O sistema organiza os vários processos no estado de espera também em listas encadeadas. Em geral os processos são separados em listas de espera associadas a cada tipo de evento (Figura 5.5). Neste caso, quando um evento acontece, todos processos da lista associada ao evento são transferidos para o estado de pronto.

5.4 Mudanças de Estado de ProcessoUm processo muda de estado durante seu processamento em função de eventos originados por ele próprio

(eventos voluntários) ou pelo SO (eventos involuntários). Basicamente apenas quatro mudanças de estados podem ocorrer:

Pronto → Execução – Após a criação de um processo, o sistema o coloca em uma lista de processos no estado de pronto, aguardando para ser executado (Figura 5.6 a). Cada SO tem sua política de escalonamento.

Execução → Espera – Um processo passa a estado de espera por eventos gerados pelo próprio processo, como uma operação de E/S, ou por eventos externos (Figura 5.6 b). Um evento externo é gerado, por exemplo, quando o SO suspende por um período de tempo a execução de um processo

Espera → Pronto – Ocorre quando uma operação solicitada é atendida ou o recurso esperado é concedido. Não existe a mudança de espera para execução diretamente (Figura 5.6 c).

Execução → Pronto – Ocorre através de eventos gerados pelo sistema, como o termino da fatia de tempo que o processo possui para sua execução (Figura 5.6 d). Então, aguarda nova oportunidade para continuar seu processamento.

Quando não houver espaço suficiente para todos os processos na memória principal, um processo em estado de pronto ou espera pode ser encontrado na memória secundária. Uma técnica conhecida como swapping retira processos da memória principal e os traz de volta segundo seus próprios critérios. Portanto, os processos em estado de espera e pronto, podem estar ou não residentes em memória principal (Figura 5.7).

Estado de Execução

Estado de Espera Estado de Pronto

a

c

db

Fig. 5.6 – Mudanças de estados do processo

32

resid en tenã o residen te

Esta d o d e Execu çã o

Esta d o d e Espera

Esta d o d e Espera

Esta do de Pro n to

Esta do de Pro n to

Fig. 5.7 – Mudanças de estado do processo (2).

5.5 Criação e Eliminação de ProcessosProcessos são criados e eliminados por diversas razões. A criação de um processo ocorre quando o SO

adiciona um novo PCB à sua estrutura e reserva espaço na memória para uso. A partir da criação do PCB, o SO já reconhece a existência do processo, passando a gerenciá-lo e associar programas ao seu contexto para serem executados. No caso da eliminação de um processo, todos recursos associados a ele são desalocados e o PCB eliminado pelo SO.

Além destes três processos, a maioria dos SOs estabelece mais dois estados para os momentos de criação e eliminação de um processo (Figura 5.8).

Estado de Execução Estado de Término

Estado de Espera Estado de Pronto Estado de C ria çã o

Fig. 5.8 – Mudanças de estado do processo (3)

33

Criação (new) – Um processo é considerado em estado de criação, quando o SO já criou um novo PCB, porém ainda não pode colocá-lo na lista de processos do estado de pronto. Alguns SOs limitam o número de processos ativos em função dos recursos disponíveis ou de desempenho. Esta limitação pode ocasionar que os processos criados permaneçam no estado de criação até que possam passar a ativos.A criação de processos pode ocorrer por razões como:- logon interativo: um processo é criado através do estabelecimento de uma sessão interativa por um usuário a partir de um terminal.- criação por um outro processo: um processo já existente pode criar outros processos, sendo estes novos independentes ou subprocessos.- criação pelo SO: o SO pode criar novos processos para oferecer algum serviço.

Terminado (exit) – Um processo no estado terminado não poderá ter mais nenhum programa executado em seu contexto, porém, o SO ainda mantém suas informações de controle na memória. Neste estado, o processo não é mais considerado ativo, mas como o PCB ainda existe, o SO pode recuperar informações sobre a contabilização de uso de recursos do processo, como o tempo total do processador. Após a extração das informações, o processo pode deixar de existir.O término de um processo pode ocorrer devido a:- término normal da execução;- eliminação por um outro processo;- eliminação forcada por ausência de recursos disponíveis no sistema.

5.6 Processos Independentes, Subprocessos e ThreadsProcessos, subprocessos e threads são maneiras diferentes de implementar a concorrência dentro de uma

aplicação. Neste caso, busca-se dividir o código em partes para trabalharem de forma cooperativa. Por exemplo, um banco de dados que recebe consultas constantes e freqüentes. Aqui, a concorrência na aplicação proporciona um tempo de espera menor entre consultas, melhorando o desempenho da aplicação e beneficiando os usuários.

O uso de processos independentes é a maneira mais simples de se implementar a concorrência em sistemas multiprogramáveis. Neste caso, não existe vínculo entre o processo criado e seu criador. A criação de um processo independente exige a locação de um PCB, possuindo contextos de hardware, software e espaço de endereçamento próprios.

Subprocessos são criados dentro de uma estrutura hierárquica. E neste caso, o processo criador é denominado processo pai e o novo processo é chamado de subprocesso ou processo filho. O subprocesso pode criar outros subprocessos. Uma característica desta implementação é a de criar dependência entre processo criador e subprocesso. Se o processo deixar de existir, também os subprocessos o farão. Assim como os processos independentes, os subprocessos também exigem seu próprio PCB. A Figura 5.9 ilustra cinco processos numa estrutura hierárquica, cada qual com seus contextos e espaços de endereçamento. Além disso, os subprocessos também podem compartilhar quotas com o processo pai. Ou seja, quando o subprocesso é criado, o processo pai cede parte de suas quotas a ele.

O uso de processos independentes e subprocessos demanda consumo de recursos, uma vez que recursos são alocados toda vez que um processo é criado, e também tempo do processador é utilizado para este trabalho. Assim também ocorre no seu término (desalocação de recursos). Mais ainda, a comunicação e sincronização entre processos é considerada pouco eficiente, visto que cada processo possui seu próprio espaço de endereçamento.

O conceito de thread foi estabelecido com a intenção de reduzir o tempo gasto na criação, eliminação e troca de contexto de processos nas aplicações concorrentes, bem como economizar recursos do sistema como um todo. Num ambiente multithread, um único processo pode suportar múltiplos threads, cada qual associado a uma parte do código da aplicação (Figura 5.10). Neste caso não é necessário haver diversos processos para implementação da concorrência. Threads compartilham o processador da mesma maneira que um processo, ou seja, enquanto espera por uma operação de E/S, outro thread pode ser executado.

34

Processo A

Processo CProcesso B

Processo EProcesso D

Figura 5.9 – Estrutura de Processos e Subprocessos

Cada thread possui seu próprio contexto de hardware, porém compartilha o mesmo contexto de software e espaço de endereçamento. O compartilhamento deste último permite que a comunicação de threads dentro de um mesmo processo seja feita de forma simples e rápida. Este assunto será melhor detalhado no capítulo seguinte.

C on textode hardw are

C on textode hardw a re

C ontextode hardw a re

Espaço deendereça men to

Cont

exto

de

softw

are

Th rea d 3Th rea d 2Th rea d 1

Fig. 5.10 – Processo Multithread

5.7 Processos Foreground e BackgroundUm processo possui sempre associado à sua estrutura, pelo menos dois canais de comunicação por onde são

realizadas todas as entradas e saídas de dados ao longo do seu processamento. Os canais de entrada (input) e de saída (output) de dados podem estar associados a terminais, arquivos, impressoras e ate mesmo outros processos.

35

Um processo foreground é aquele que permite a comunicação direta do usuário com o processo durante sua execução. Assim, ambos os canais estão associados a um terminal com teclado, mouse e monitor, permitindo portanto, a interação com o usuário (Figura 5.11a). O processamento interativo tem com base processos foreground.

Um processo background é aquele onde não existe a comunicação com o usuário durante seu processamento (Figura 5.11b). Aqui, os canais de E/S não estão associados a nenhum dispositivo de E/S interativo, mas em geral a arquivos de E/S. O processamento batch, por exemplo, é realizado através de processos background.

Quando o canal de saída de um processo estiver associado ao canal de entrada de outro processo, dizemos que existe um pipe ligando ambos os processos. Por exemplo, se um processo A gera uma listagem e o processo B tem como função ordená-la, basta associar o canal de saída do processo A ao canal de entrada do processo B (Figura 5.12).

(a ) Pro cesso Fo regrou nd

(b ) Processo Ba ckground

sa ída

sa ída

a rqu ivode sa ída

term ina lterm ina l

en trad a

entrad a

arqu ivode entrada

Fig. 5.11 – Processos foreground e background

entrada doProcesso A

sa ída doProcesso B

sa ída doProcesso A

entrada doProcesso B

Processo A Pro cesso B

Figura 5.12 – Pipe

5.8 Processos do Sistema OperacionalO conceito de processo, além de estar associado a aplicações de usuários, podem também ser implementados

na própria arquitetura do SO. Como visto em capítulo anterior, a arquitetura microkernel implementa uso intensivo de processos que disponibilizam serviços para processos das aplicações e do próprio SO.

Quando processos são utilizados para a implementação de serviços do sistema, estamos retirando códigos de seu núcleo, tornando-o menor e mais estável. No caso de um ou mais serviços não serem desejados, basta não ativar os processos responsáveis, o que permitirá liberar memória para os processos dos usuários.

Alguns serviços que o SO pode implementar através de processos são:

auditoria e segurança; serviços de rede;

36

contabilização do uso de recursos; contabilização de erros; gerência de impressão; gerência de jobs match; temporização; comunicação de eventos; interface de comandos.

5.9 Processos CPU-Bound e I/O-BoundOs processos podem ser classificados como CPU-Bond ou I/O-Bond, de acordo dom a utilização do

processador e dos dispositivos de E/S.Um processo é definido como CPU-Bound (ligado à CPU), quando passa a maior parte do tempo no estado

de execução, ou seja, utilizando o processador (Figura 5.13a). Este tipo de processo realiza poucas operações de leitura e gravação e é encontrado em aplicações científicas que efetuam muitos cálculos.

Por outro lado, um processo I/O-Bound (ligado à E/S) passa a maior parte do tempo no estado de espera, pois realiza grande número de operações de E/S (Figura 5.13b). Aplicações comerciais, que se baseiam em leitura, processamento e gravação são exemplos de processos deste tipo, assim como também os processos interativos, pela forma de comunicação entre o usuário e o sistema, normalmente lenta, devido ao uso de terminais.

(a ) C PU - b o u ndtem po tem po

E/ S E/ S

U C P U C P

(b ) I / O -b ou n d

Fig. 5.13 – Processos CPU-bound x I/O-bound

5.10 SinaisSinais são um mecanismo que permite notificar processos de eventos gerados pelo sistema operacional ou

por outros processos. O uso de sinais é fundamental para a gerência de processos, além de possibilitar a comunicação e sincronização entre processos.

Por exemplo, ao se teclar simultaneamente as teclas Ctrl e C, para interromper um programa, o SO gera um sinal ao processo, sinalizando a ocorrência do evento. O processo identificando o sinal, uma rotina especial de tratamento é executada (Figura 5.14).

[ctrl- C ]Processo

interru pção sina lSistema O peracion a l

Fig. 5.14 – Uso de Sinais

Os sinais podem ser usados em conjunto com temporizadores com a intenção de sinalizar ao processo algum evento associado ao tempo. Por exemplo, um processo que deve ser avisado periodicamente sobre uma tarefa a realizar, como monitorar uma fila de pedidos. Após a realização da tarefa, o processo retorna à espera do próximo sinal.

37

A maior parte dos eventos associados a sinais são gerados pelo SO ou pelo hardware, como as exceções, interrupções, limites de quotas excedidos e alarmes de tempo. Em outros casos, os eventos são gerados a partir de outros processos com o propósito de sincronizar suas execuções.

A geração de um sinal ocorre quando o SO, a partir da ocorrência de eventos síncronos ou assíncronos, notifica o processo através de bits de sinalização localizados no seu PCB. Um processo não responde instantaneamente a um sinal. Os sinais ficam pendentes até que o processo seja escalonado, quando então serão tratados. Por exemplo, na eliminação de um processo, o sistema ativa o bit associado a este evento. O processo só será excluído do sistema quando for selecionado para execução. Assim, é possível que o processo demore algum tempo até ser eliminado de fato.

O tratamento de um sinal é bem semelhante ao de uma interrupção. Quando um sinal é tratado, o contexto do processo é salvo e a execução desviada para um código de tratamento de sinal (signal handler), geralmente no núcleo do SO. Após a execução do tratador de sinais, o programa pode voltar a ser processado do ponto onde foi interrompido. Às vezes, o próprio processo pode tratar o sinal através de um tradutor de sinais definido no código do programa. É possível também que um processo bloqueie temporariamente ou ignore por completo alguns sinais.

Apesar do mecanismo ser parecido com o do tratamento de interrupções e exceções, os propósitos são diferentes. O sinal está para o processo assim como as interrupções e exceções estão para o sistema operacional (Figura 5.15)

H ardw a re

Sistem a O p era cio n a l

In terrup çõ esExceções

Sin a is

Processo Processo

Fig. 5.15 – Sinais, interrupções e exceções.

38

Material de apoio para a realização do Segundo Seminário

Arquitetura de Sistemas Operacionais

Capítulo 6

THREAD

6.1 IntroduçãoAté o final dos anos 70, os SOs suportavam processos com apenas um thread (monothread), ou seja, um

processo com apenas um programa fazendo parte de seu contexto. Em 1979, introduziu-se o conceito de processos “ligthweight” (peso leve), onde o espaço de endereçamento de um processo era compartilhado por vários programas. Porém, esta idéia não foi utilizada comercialmente, e apenas na metade da década de 80, com o SO Mach, ficou clara a separação entre os conceitos de processo e thread.

Com o conceito de múltiplos threads (multithread), pode-se projetar aplicações concorrentes de forma eficiente, pois um processo pode ter diferentes partes de seu código sendo executadas em paralelo. Como os threads de um mesmo processo compartilham o mesmo espaço de endereçamento, a comunicação entre threads não envolve mecanismos lentos de intercomunicação entre processos, aumentando assim o desempenho da comunicação.

O desenvolvimento de programas que exploram os benefícios da programação multithread não é simples. A presença do paralelismo introduz um novo conjunto de problemas, como a comunicação e sincronização de threads. Existem diferentes modelos para a implementação de threads em um SO, onde desempenho, flexibilidade e custos devem ser avaliados.

Atualmente, o conceito de multithread pode ser encontrado em sistemas como Sun Solaris e Windows 2000. A utilização comercial de sistemas multithreads tem crescido devido ao aumento de popularidade de sistemas com multiprocessadores, do modelo cliente-servidor w dos sistemas distribuídos.

6.2 Ambiente MonothreadUm programa é uma seqüência de instruções, compostas de desvios, repetições e chamadas a procedimentos

e funções. Em um ambiente monothread, um processo suporta apenas um programa em seu espaço de endereçamento. Neste ambiente, aplicações concorrentes são implementadas apenas com o uso de múltiplos processos independentes ou subprocessos.

O uso de processos independentes e subprocessos permite dividir uma aplicação em partes que podem trabalhar de forma concorrente. Por exemplo, um usuário pode estar lendo seus e-mails antigos, ao mesmo tempo em que estaria enviando e recebendo e-mails atuais. Co o uso de múltiplos processos, cada funcionalidade do software implicaria na criação de um novo processo para atendê-lo, aumentando o desempenho da aplicação (Figura 6.1).

Um problema é que o uso de processos no desenvolvimento de aplicações concorrentes demanda consumo de diversos recursos do sistema. Sempre que um novo processo é criado, o sistema deve alocar recursos para cada processo, consumindo tempo de processador neste trabalho. No caso do término do processo, o sistema dispensa tempo para desalocar recursos previamente alocados.

Outro problema a ser considerado é quanto ao compartilhamento do espaço de endereçamento. Como cada processo possui seu próprio espaço de endereçamento, a comunicação entre processos torna-se difícil e lenta, pois utiliza mecanismos como pipes, sinais, semáforos, memória compartilhada ou troca de mensagem. Além disso, o compartilhamento de recursos comuns aos processos concorrentes, como memória e arquivos abertos, não é simples. Na Figura 6.2 existem três processos monothread, cada um com seu próprio contexto de hardware, de software e espaço de endereçamento.

39

Subprocessos Processo s In dep endentes

Fig. 6.1 – Concorrência com subprocessos e processos independentes

São exemplos de sistemas monothread o MS-DOS e as primeiras versões do Windows. Mesmo em ambientes multiprogramáveis e multiusuários, encontra-se exemplos de implementações monothread, como nas versões mais antigas dos sistemas VAX/VMS e Unix.

Th rea d Th rea dTh rea d

Fig. 6.2 – Ambiente monothread

6.3 Ambiente MultithreadEm um ambiente multithread, ou seja, com múltiplos threads, não existe a idéia de programas associados a

processos, mas sim a threads. O processo, neste ambiente, tem pelo menos um thread em execução, mas pode compartilhar o seu espaço de endereçamento com inúmeros outros threads. Na Figura 6.3 existe apenas um processo com três threads de execução compartilhando o mesmo espaço de endereçamento.

C on textode h ard w a re

C ontextode h ard w a re

C ontextode h ard w a re

Esp aço deen dereçam ento

Cont

exto

de

softw

are

Th rea d 3Th rea d 2Threa d 1

Fig. 6.3 – Ambiente Multithread

40

De forma simplificada, um thread pode ser definido como uma sub-rotina de um programa que pode ser executada de forma assíncrona, ou seja, executada paralelamente ao programa chamador. O programador deve especificar os threads, associando-os às sub-rotinas assíncronas. Assim, um ambiente multithread possibilita a execução concorrente de sub-rotinas dentro de um mesmo processo.

Na Figura 6.4 existe um programa principal que realiza a chamada de suas sub-rotinas assíncronas (Sub_1 e Sub_2). Inicialmente, o processo é criado apenas com o Thread_0 para a execução do programa principal. Quando o programa principal chama as duas sub-rotinas, são criados os Thread_1 e Thread_2, e executados independentemente do programa principal. Neste processo, os três threads são executados concorrentemente.

No ambiente multithread, cada processo pode responder a varias solicitações concorrentemente ou mesmo simultaneamente, caso haja mais de um processador. A grande vantagem no uso de threads é a possibilidade de minimizar a alocação de recursos do sistema, alem de diminuir o overhead na criação, troca e eliminação de processos.

Threads compartilham o processador da mesma maneira que processos e passam pelas mesmas mudanças de estado (execução, espera e pronto). Por exemplo, enquanto um thread espera por uma operação de E/S, outro thread pode ser executado. Para permitir a troca de contexto entre os diversos threads, cada um possui seu próprio contexto de hardware, com o conteúdo dos registradores gerais, PC e SP. Quando um thread está sendo executado, seu contexto hardware está armazenado nos registradores do processador. No momento em que o thread perde a utilização do processador, as informações são atualizadas no seu contexto de hardware.

Esp aço deen dereçamen to

Processo

Program a Pr in cipa l

Cont

exto

de

Hard

ware

Cont

exto

de

Hard

war

eCo

ntex

to d

eHa

rdw

are

C a l l Su b_1

C a l l Su b_2

Threa d_1

Threa d_2

Threa d_3

PCSP

PCSP

PCSP

Fim

Sub _2

Va riáveis

Ret

Sub _1

Ret

......

Fig. 6.4 – Aplicação Multithread (a)

Dentro de um mesmo processo, threads compartilham o mesmo contexto de software e espaço de endereçamento com os demais threads, porém cada thread possui seu contexto de hardware individual. Threads são implementados internamente através de uma estrutura de dados denominada bloco de controle do thread (Thread

41

Control Block – TCB). O TCB armazena, além do contexto de hardware, mais algumas informações relacionadas exclusivamente ao thread, como prioridade, estado de execução e bits de estado.

Em ambientes monothread, o processo é ao mesmo tempo a unidade de alocação de recursos e a unidade de escalonamento. A independência entre os conceitos de processo e thread permite separar a unidade de alocação de recursos da unidade de escalonamento, que em ambientes monothread estão fortemente relacionadas. Em um ambiente multithread, a unidade de alocação de recursos é o processo, onde todos os seus threads compartilham o espaço de endereçamento, descritores de arquivos de dispositivos de E/S. Por outro lado, cada thread representa uma unidade de escalonamento independente. Neste caso, o sistema não seleciona um processo para a execução, mas sim um de seus threads.

A grande diferença entre aplicações mono e multithread está no uso do espaço de endereçamento. Processos independentes e subprocessos possuem espaços de endereçamento individuais e protegidos, enquanto threads compartilham o espaço dentro de um mesmo processo. Isso permite que o compartilhamento de dados entre threads de um mesmo processo seja mais simples e rápido, se comparado a ambientes monothreads.

Como threads de um mesmo processo compartilham o mesmo espaço de endereçamento, não existe qualquer proteção no acesso à memória, permitindo que um thread possa alterar facilmente dados de outros. Para que os threads trabalhem de forma cooperativa, é fundamental que a aplicação implemente mecanismos de comunicação e sincronização entre threads, a fim de garantir o acesso seguro aos dados compartilhados na memória.

O uso de multithreads proporciona uma serie de benefícios. Programas concorrentes com múltiplos threads são mais rápidos do que programas concorrentes implementados com múltiplos processos, pois operações de criação, troca de contexto e eliminação dos threads geram menor overhead (Tabela 6.1). Como os threads dentro de um processo dividem o mesmo espaço de endereçamento, a comunicação entre eles pode ser realizada de forma rápida e eficiente. Além disso, threads em um mesmo processo podem compartilhar facilmente outros recursos, como descritores de arquivos, temporizadores, sinais, atributos de segurança, etc.

Implementação Tempo de criação (μs) Tempo de sincronização (μs)Processo 1700 200

Processo Lightweight 350 390Thread 52 66

Tabela 6.1 – Latência de Processos e Threads

A utilização do processador, dos discos e outros periféricos pode ser feita de forma concorrente pelos diversos threads, significando melhor utilização dos recursos computacionais disponíveis. Em algumas aplicações, a utilização de threads pode melhorar o desempenho da aplicação apenas executando tarefas em background enquanto operações E/S estão sendo processadas (Figura 6.5). Aplicações como editores de texto, planilhas, aplicativos gráficos e processadores de imagem são especialmente beneficiados quando desenvolvidos com base em threads.

Em ambientes cliente-servidor, threads são essenciais para solicitação de serviços remotos. Em um ambiente monothread, se uma aplicação solicita um serviço remoto, ela pode ficar esperando indefinidamente, enquanto aguarda pelo resultado. Em um ambiente multithread, um thread pode solicitar o serviço remoto, enquanto a aplicação pode continuar realizando outras atividades. Já para o processo que atende a solicitação, múltiplos threads permitem que diversos pedidos sejam atendidos simultaneamente (Figura 6.6).

42

Th read deen trada

Th read deg ravaçã o

Thread d eexibição

Buffer

Fig. 6.5 – Aplicação Multithread (b)

So licitações

Processo servido r

ThreadTh rea d

Pro cesso clientePro cesso cliente Pro cesso cliente

Th read

Fig. 6.6 – Aplicação multithread (c)

43

Não apenas aplicações tradicionais podem fazer uso dos benefícios do multithreading. O núcleo do SO também pode ser implementado com o uso desta técnica de forma vantajosa, como na arquitetura microkernel, apresentada em capítulo anterior.

6.4 Arquitetura e ImplementaçãoO conjunto de rotinas disponíveis para que uma aplicação utilize as facilidades dos threads é chamado de

pacote de threads. Existem diferentes abordagens na implementação deste pacote em um SO, o que influenciará no desempenho, na concorrência e na modularidade das aplicações multithread.

Threads podem ser oferecidos por uma biblioteca de rotinas fora do núcleo do SO (modo usuário), pelo próprio núcleo do sistema (modo kernel), por uma combinação de ambos (modo híbrido) ou por um modelo conhecido como “scheduler activations”. A Tabela 6.2 resume as diversas arquiteturas para diferentes ambientes operacionais.

Ambientes ArquiteturaDistributed Computing Environment (DCE) Modo UsuárioCompaq Open VMS versão 6 Modo UsuárioMS Windows 2000 Modo KernelCompaq Unix Modo KernelCompaq Open VMS versão 7 Modo KernelSun Solaris versão 2 Modo HíbridoUniversity of Washington FastThreads Scheduler Activations

Tabela 6.2 – Arquitetura de threads para diversos ambientes operacionais

Uma das grandes dificuldades para a utilização de threads foi a ausência de um padrão. Em 1995, o padrão POSIX P1003.1c foi aprovado e posteriormente atualizado para a versão POSIX 1003.4 a. Com este padrão, também conhecido como Pthreads, aplicações comerciais multithreading tornaram-se mais simples e de fácil implementação. O padrão Pthreads é largamente utilizado em ambientes Unix, como o Sun Solaris Pthreads e o DECthreads para Digital OSF/1.

6.4.1 Threads em Modo UsuárioThreads em modo usuário (TMU) são implementados pela aplicação e não pelo SO. Para isso, deve existir

uma biblioteca de rotinas que possibilite a aplicação realizar tarefas como criação/eliminação de threads, troca de mensagens entre threads e uma política de escalonamento. Neste modo, o SO não sabe da existência de múltiplos threads, sendo responsabilidade exclusiva da aplicação gerenciar e sincronizar os diversos threads existentes.

A vantagem deste modelo é a possibilidade de implementar aplicações multithreads mesmo em SOs que não suportem threads. Utilizando biblioteca, múltiplos threads podem ser criados, compartilhando o mesmo espaço de endereçamento do processo, além de outros recursos (Figura 6.7). TMU são rápidos e eficientes por dispensarem acessos ao kernel do SO, evitando assim a mudança de modo de acesso (usuário-kernel-usuário).

Os TMU possuem uma grande limitação, pois o SO gerencia cada processo como se existisse apenas um thread. Quando o thread chama uma rotina do sistema que o coloca em estado de espera (rotina bloqueante), todo o processo é colocado no estado de espera, mesmo havendo outros threads prontos para execução. Para contornar esta limitação, a biblioteca tem que possuir rotinas que substituam as rotinas bloqueantes por outras que não possam causar o bloqueio de um thread (rotinas não-bloqueantes). Todo este controle é transparente para o usuário e para o SO.

44

M odou suá rio

M odokernelKernel

Bib lio tecaTh

read

0

Thre

ad 4

Thre

ad 3

Thre

ad 2

Thre

ad 1

Figura 6.7 – Threads em modo usuário

Talvez um dos maiores problemas na implementação de TMU seja o tratamento individual de sinais. Como o sistema reconhece apenas processos e não threads, os sinais enviados para um processo devem ser reconhecidos e encaminhados a cada thread para tratamento. No caso do recebimento de interrupções de clock, fundamental para implementação do tempo compartilhado, esta limitação é crítica. Neste caso, os sinais de temporização devem ser interceptados, para que se possa interromper o thread em execução e realizar a troca de contexto.

Em relação ao escalonamento em ambientes com múltiplos processadores, não é possível que múltiplos threads de um processo possam ser executados em diferentes processadores simultaneamente, pois o sistema seleciona apenas processos para execução e não threads. Esta restrição limita drasticamente o grau de paralelismo da aplicação, já que os threads de um mesmo processo podem ser executados em somente um processador de cada vez.

6.4.2 Threads em Modo KernelThreads em Modo Kernel (TMK) são implementados diretamente pelo núcleo do SO, através de chamadas a

rotinas do sistema que oferecem todas as funções de gerenciamento e sincronização (Fig. 6.8). O S.O. sabe da existência de cada thread e pode escaloná-los individualmente. No caso de múltiplos processadores, os threads de um mesmo processo podem ser executados simultaneamente.

O grande problema para pacotes em modo kernel é o seu baixo desempenho. Enquanto nos pacotes em modo usuário todo tratamento é feito sem ajuda do SO, ou seja, sem a mudança do modo de acesso (usuário-kernel-usuário), pacotes em modo kernel utilizam chamadas a rotinas do sistema e, conseqüentemente, várias mudanças no modo de acesso. A Tabela 6.3 compara o desempenho de duas operações distintas envolvendo a criação, escalonamento, execução e eliminação de um processo/thread.

M odou suá rio

M odokerne lKernel

Bib lio teca

Thre

ad 0

Thre

ad 4

Thre

ad 3

Thre

ad 2

Thre

ad 1

Figura 6.8 – Threads em Modo Kernel

45

Implementação Operação 1 (μs) Operação 2 (μs)Subprocessos 11.300 1.840

Threads em Modo Kernel 948 441Threads em Modo Usuário 34 37

Tabela 6.3 – Comparação entre tempos de latência

6.4.3 Threads em Modo HíbridoA arquitetura de threads em modo híbrido combina as vantagens de threads implementados em modo usuário

(TMU) e threads em modo kernel (TMK). Um processo pode ter vários TMKs, e por sua vez, um TMK pode ter vários TMUs. O núcleo do SO reconhece os TMKs e pode escaloná-los individualmente. Um TMU pode ser executado em um TMK, em um determinado momento, e no instante seguinte ser executado em outro.

O programador desenvolve a aplicação em termos de TMU e especifica quantos TMK estão associados ao processo. Os TMUs são mapeados em TMK enquanto o processo está sendo executado. O programador pode utilizar apenas TMK, TMU ou uma combinação de ambos (Figura 6.9).

O modo híbrido, apesar de maior flexibilidade, apresenta problemas herdados de ambas as implementações. Por exemplo, quando um TMK realiza uma chamada bloqueante, todos os TMUs são colocados no estado de espera. TMUs que desejam utilizar vários processos deve utilizar diferentes TMKs, o que influenciará no desempenho.

M odou suá rio

M odokernel

K ernel

TM K 0 TM K 3TM K 2TM K 1

Bib lio teca

TMU

0

TMU

4

TMU

5

TMU

3

TMU

2

TMU

1

Figura 6.9 – Threads em modo híbrido

6.4.4 Scheduler ActivationsOs problemas apresentados no pacote de threads em modo híbrido existem devido à falta de comunicação

entre threads em modo usuário e em modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em modo kernel com o desempenho e flexibilidade do modo usuário.

Introduzido no início dos anos 90, este pacote combina o melhor das duas arquiteturas, mas em vez de dividir os threads em modo usuário entre os de modo kernel, o núcleo do sistema troca informações com a biblioteca de threads utilizando uma estrutura de dados chamada scheduler activations (Figura 6.10).

A maneira de alcançar um melhor desempenho é evitar as mudanças de modos de acesso desnecessárias (usuário-kernel-usuário). Caso um thread utilize uma chamada ao sistema que o coloque no estado de espera, não é necessário que o kernel seja ativado, bastando que a própria biblioteca em modo usuário escalone outro thread. Isto é possível porque a biblioteca em modo usuário e o kernel se comunicam e trabalham de forma cooperativa. Cada camada implementa seu escalonamento de forma independente, porem trocando informações quando necessário.

46

M odousuá rio

M odokernelKernel

Bib lio teca

Thre

ad 0

Thre

ad 4

Thre

ad 3

Thre

ad 2

Thre

ad 1

Figura 6.10 – Scheduler activations

6.5 Modelos de ProgramaçãoO desenvolvimento de aplicações multithread não é simples, pois exige que a comunicação e o

compartilhamento de recursos entre os diversos threads seja feito de forma sincronizada para evitar problemas de inconsistências e deadlock. Além das dificuldades naturais no desenvolvimento de aplicações concorrentes, o procedimento de depuração é bastante complexo.

Um fator importante em aplicações multithread é o numero total de threads e a forma como são criados e eliminados. Se uma aplicação cria um numero excessivo de threads, poderá ocorrer um overhead no sistema, ocasionando uma queda de desempenho.

Dependendo da implementação, a definição do numero de threads pode ser dinâmica ou estática. Quando a criação/eliminação é dinâmica, os threads são criados/eliminados conforme a demanda da aplicação, oferecendo grande flexibilidade. Já em ambientes estáticos, o número de threads é definido na criação do processo onde a aplicação será executada.

Para obter os benefícios do uso de threads, uma aplicação deve permitir que partes diferentes de seu código sejam executadas em paralelo de forma independente. Se um aplicativo realiza várias operações de E/S e trata eventos assíncronos, a programação multithread aumenta seu desempenho até mesmo em ambientes com um fraco processador. Sistemas gerenciadores de banco de dados (SGBDs), servidores de arquivo ou impressão são exemplos onde o uso de múltiplos threads proporciona grandes vantagens e benefícios.

47

Capítulo 7

Sincronização e Comunicação entre processos

7.1 IntroduçãoCom o surgimento dos SOs multiprogramáveis, tornou-se possível estruturar aplicações de maneira que

partes diferentes do código do programa pudessem ser executadas concorrentemente. Este tipo de aplicação foi denominada de aplicação concorrente.

Em sistemas com um único processador, os processos alternam sua execução segundo escalonamento estabelecido pelo SO e mesmo assim aplicações concorrentes obtêm melhoras em seu desempenho. Em sistemas com múltiplos processadores, estendem-se estas vantagens com a possibilidade do paralelismo na execução de instruções.

Os processos de uma aplicação concorrente podem compartilhar recursos, como arquivos registros, dispositivos de E/S e áreas de memória. Este compartilhamento pode gerar situações indesejáveis, capazes de comprometer a execução das aplicações. Para evitar este tipo de problema, os processos devem ter suas ações sincronizadas, através de mecanismos oferecidos pelo SO.

7.2 Aplicações ConcorrentesEm aplicações concorrentes, pode ser necessário que os processos comuniquem-se entre si. Esta

comunicação pode ser implementada através de variáveis compartilhadas na memória principal ou trocas de mensagens. Mais uma vez, é necessário que haja sincronização entre a execução dos processos concorrentes.

A figura 7.1 apresenta um exemplo onde dois processos concorrentes compartilham um buffer para troca de informações. Aqui, um processo só poderá gravar dados no buffer se ele estiver vazio, e só poderá ler um dado do buffer caso haja um dado a ser lido. Em ambos os casos, os processos deverão esperar até que o buffer esteja pronto para as operações de gravação e leitura.

Processogra vad or

Processoleito r

da do

Sin cron iza çã o

leitu rag ra vaçã o

Bu ff erFigura 7.1 – Sincronização e Comunicação entre processos

Os mecanismos que realizam a comunicação entre processos concorrentes e o acesso a recursos compartilhados são chamados de mecanismos de sincronização. Em SOs multiprogramáveis estes mecanismos são fundamentais para garantir a integridade e confiabilidade na execução de aplicações concorrentes.

7.3 Especificação de Concorrência em ProgramasExistem varias notações para especificar quais partes de um programa que devem ser executadas

concorrentemente. Técnicas mais recentes tentam expressar a concorrência no código dos programas de uma forma mais clara e estruturada.

As primeiras notações para especificar uma concorrência em um programa foram os comandos FORK e JOIN. O exemplo abaixo exemplifica de forma simplificada este uso.

PROGRAMA A; PROGRAMA B;. .. .FORK B; .. .. .JOIN B; END...

END.48

O Programa A começa a ser executado e, ao encontrar o comando FORK, faz com que seja criado um outro processo para execução do Programa B, concorrentemente ao Programa A. O comando JOIN faz com que o Programa A sincronize-se com o B, ou seja, o Programa A só continuará a ser executado após o término da execução de B. Os comandos FORK e JOIN são poderosos e práticos, sendo utilizados de forma semelhante no Sistema Unix.

Outra forma mais clara e simples de expressar concorrência em um programa é com o uso dos comandos PARBEGIN e PAREND (1965), que posteriormente foram chamados de COBEGIN e COEND. Aqui continuaremos a utilizar os comandos PARBEGIN e PAREND.

A figura 7.2 demonstra o uso dos comandos PARBEGIN e PAREND.

Processoprincipa l

Processoprincipa l

Processo 1 Pro cesso 2 Processo n

PARBEGIN Comando_1; Comando_2; . . Comando_n;PAREND

Figura 7.2 – Concorrência em programas

Para exemplificar o uso destes comandos, o programa chamado EXPRESSAO realiza um cálculo do valor da expressão descrita a seguir:

X := SQRT (1024) + (35.4 * 0.23) – (302 / 7)

Os comandos situados entre PARBEGIN e PAREND são executados concorrentemente. O cálculo final de X só poderá ser realizado quando todas as variáveis dentro da estrutura estiverem sido calculadas.

PROGRAM Expressao; VAR X, Temp1, Temp2, Temp3 : REAL;BEGIN PARBEGIN Temp1 := SQRT (1024); Temp2 := 35.4 * 0.23; Temp3 := 302 / 7; PAREND; X := Temp1 + Temp2 - Temp3; WRITELN ('x = ', X);END.

49

7.4 Problemas de Compartilhamento de RecursosPara melhor compreensão da importância da sincronização entre processos concorrentes, são apresentados

alguns exemplos-problema de compartilhamento de recursos. O primeiro problema é analisado a partir do programa Conta_Corrente, que atualiza o saldo bancário de um

cliente após o lançamento de débito ou crédito no arquivo de contas-correntes Arq_Contas. Neste arquivo são armazenados os saldos de todos os correntistas do banco. O programa lê o registro do cliente no arquivo (Reg_Cliente), lê o valor a ser depositado ou retirado (Valor_Dep_Ret) e, em seguida atualiza o saldo no arquivo de contas.

PROGRAM Conta_Corrente; . . READ (Arq_Contas, Reg_Cliente); READLN (Valor_Dep_Ret); Reg_Cliente.Saldo := Reg_Cliente.Saldo + Valor_Dep_Ret; WRITE (Arq_Contas, Reg_Cliente); . .END.

Considerando processos concorrentes pertencentes a dois funcionários do banco que atualizam o saldo de um mesmo cliente simultaneamente, a situação de compartilhamento do recurso pode ser analisada. O processo do primeiro funcionário (Caixa 1) lê o registro do cliente e soma ao campo Saldo o valor do lançamento de débito. Antes de gravar o novo saldo no arquivo, o processo do segundo funcionário (Caixa 2) lê o registro do mesmo cliente, que está sendo atualizado, para realizar outro lançamento, desta vez de crédito. Independente de qual processo atualize primeiro o saldo no arquivo, o dado gravado estará inconsistente. Acompanhe:

Caixa Comando Saldo Arquivo Valor Dep/Ret Saldo Memória1 READ 1.000 * 1.0001 READLN 1.000 -200 1.0001 := 1.000 -200 8002 READ 1.000 * 1.0002 READLN 1.000 +300 1.0002 := 1.000 +300 1.3001 WRITE 800 -200 8002 WRITE 1.300 +300 1.300

Outro exemplo simples é a situação onde dois processos (A e B) executam um comando de atribuição. O processo A soma 1 à variável X e o processo B subtrai 1 da mesma variável. Suponha que inicialmente a variável X possua o valor 2.

Processo A Processo BX: = X + 1 ; X: = X – 1;

Seria razoável pensar que no final das operações a variável continuasse valendo 2, porem nem sempre isso será verdade. Decompondo em operações mais elementares, usando uma linguagem de alto nível, temos:

Processo A Processo BLoad x, Ra Load x, RbAdd 1,Ra Sub 1,RbStore Ra,x Store Rb,x

Considere que o Processo A carregue o valor de X no Registrador Ra, some 1, e no momento em que vai armazenar o novo valor de X, seja interrompido. Neste instante, inicia-se o Processo B, que carrega o valor de X em Rb e subtrai o valor 1. Agora o Processo B é interrompido e o A volta a ser executado, atribuindo o valor 3 à variável X e finalizando sua execução. O Processo B retorna sua execução, atribui o valor 1 a X e sobrepõe o valor anteriormente gravado pelo Processo ª O resultado final será inconsistente. Resumindo:

50

Processo Comando X Ra RbA Load X,Ra 2 2 *A Add 1,Ra 2 3 *B Load X,Rb 2 * 2B Sub 1,Rb 2 * 1A Store Ra,X 3 3 *B Store Rb,X 1 * 1

Através destes exemplos, conclui-se que quando dois ou mais processos compartilham um mesmo recurso, alguns mecanismos devem evitar que este tipo de problema ocorra (conhecidos como race conditions – condições de corrida).

7.5 Exclusão MútuaPara que sejam evitados problemas desta natureza, onde dois processos manipulem o mesmo arquivo ou a

mesma variável de memória simultaneamente, enquanto um processo estiver acessando determinado recurso, todos os outros que queiram acessar esse mesmo recurso deverão esperar. Isso se chama EXCLUSÃO MUTUA (Mutual Exclusion).

A exclusão mútua deverá agir apenas sobre os processos que estão concorrendo em um determinado recurso. Quando desenvolvemos um programa, que faça tratamento de exclusão mútua, este deverá terá uma seção chamada REGIÃO CRÍTICA (Critical Region). Nesta região existe uma série de procedimentos e protocolos que o programa deverá fazer para que o sistema operacional libere o recurso para o mesmo. Toda vez que um processo desejar executar instruções de sua região crítica, obrigatoriamente devera executar antes um protocolo de entrada nessa região. Da mesma forma, ao sair da região crítica um protocolo de saída deverá ser executado. A região critica deve ser sempre usada quando seu programa for fazer uso de recursos que são passiveis de compartilhamento com algum outro suposto programa na memória. É nela também que os processos encontram-se em um momento mais critico, pois qualquer erro ocorrido ali dentro pode fazer com que dois ou mais processos colidam gerando falhas e derrubando o sistema.

Assim, para garantir a implementação da exclusão mútua, os processos envolvidos devem fazer acesso aos recursos de forma sincronizada. Diversas soluções foram criadas com este propósito; porém, ainda existem duas situações que devem ser evitadas

.7.5.A StarvationA primeira situação indesejada é conhecida como starvation (ou espera indefinida).Quem determina as prioridades dos processos é o sistema operacional. Neste caso existem duas formas do

sistema operacional determinar qual será a vez de quem. Ou por escolha aleatória ou por prioridades. Quando a escolha é aleatória, existirá a probabilidade de um processo nunca ser escolhido. Quando for uma escolha por prioridades, um processo de menor prioridade nunca receberá o acesso ao recurso, e ai este processo nunca executará sua rotina.

Uma solução bastante simples é a criação de filas de pedidos de alocação para cada recurso, utilizando o esquema FIFO (First In First Out). Sempre que um processo solicita um recurso, o pedido é colocado no final da fila associada ao recurso. Quando o recurso é liberado, o sistema seleciona o primeiro processo da fila.

7.5.B Sincronização condicionalSincronização Condicional é uma situação onde o acesso a um recurso compartilhado exige a sincronização

de processos vinculada a uma condição de acesso. Quando um recurso não está pronto para ser utilizado, o processo que vai acessar o recurso ficará em estado

de espera até que o mesmo esteja pronto. Existe o risco deste recurso nunca ficar pronto por já estar com problemas. Ai todo o sistema fica esperando o recurso resolver sua vida. Um exemplo disto é o caso do uso de Buffers para leitura e gravação de dados feita pelos processos. Uma possível falha na memória que impeça o acesso aos buffers e todo o sistema estará parado...

Diversas soluções foram propostas para garantir a exclusão mútua de processos concorrentes. A seguir, algumas soluções de hardware e software serão apresentadas, com comentários sobre suas vantagens e desvantagens.

7.5.1 Soluções de Hardware

Desabilitação de interrupçõesFaz com que o processo, antes de entrar em sua região crítica desabilite todas as interrupções externas e a

reabilite após deixar a região critica. Como a mudança de contexto de processos só pode ser realizada através de interrupções, o processo que as desabilitou terá acesso exclusivo garantido.

51

Apesar de simples, esta solução apresenta limitações. Primeiramente, a multiprogramação fica comprometida, uma vez a concorrência entre processos entre processos tem como base o uso da interrupção. Um caso mais grave poderia ocorrer caso um processo desabilitasse as interrupções e não tornasse a habilitá-las. Neste caso, o sistema provavelmente teria seu funcionamento comprometido.

Em sistemas com múltiplos processadores esta solução torna-se ineficiente devido ao tempo de propagação quando um processador sinaliza aos demais que as interrupções devem ser habilitadas ou desabilitadas. Ainda, o mecanismo de clock do sistema é implementado através de interrupções, portanto esta solução deve ser implementada com muito critério.

Apesar destas limitações, esta solução pode ser útil quando se deseja que a execução de parte do núcleo do SO ocorra sem que haja interrupção. Desta forma, o sistema pode garantir que não ocorrerão problemas de inconsistência em suas estruturas de dados durante a execução de algumas rotinas.

Instrução test-and-setMuitos processadores possuem uma instrução especial onde um processo apenas lê o conteúdo de uma

variável, e armazena seu valor em outra área podendo neste caso fazer todas as manipulações necessárias e devidas sem precisar de prioridades ou esperar que a variável original seja liberada. Esta instrução é chamada de test-and-set e tem como característica ser executada sem interrupção, ou seja, trata-se de uma instrução invisível. Assim garante-se que dois processos não manipulem uma variável compartilhada ao mesmo tempo, possibilitando a implementação da exclusão mútua.

O uso desta instrução especial oferece vantagens, como a simplicidade de implementação da exclusão mútua em múltiplas regiões críticas e o uso da solução em arquiteturas com múltiplos processadores. A principal desvantagem é a possibilidade do starvation, pois a seleção do processo para o acesso ao recurso é arbitrária.

7.5.2 Soluções de softwareDiversos algoritmos foram propostos na tentativa de implementar a exclusão mútua através de soluções de

software. As primeiras soluções tratavam apenas da exclusão mútua para dois processos e, inicialmente, apresentavam alguns problemas. A evolução ocorreu até uma solução definitiva para a exclusão mútua para N processos.

Além da exclusão mútua, que soluciona os problemas de compartilhamento de recursos, existem outros fatores fundamentais para a solução de problemas de sincronização:- O número de processadores e o tempo de execução dos processos. - Um processo fora de sua região crítica não pode impedir que outros processos entrem em suas próprias regiões críticas. - Um processo não pode permanecer indefinidamente esperando para entrar em sua região crítica.

Todas as soluções que foram apresentadas para contornar estes inconvenientes apresentavam problemas da ESPERA OCUPADA, Na espera ocupada, todas vezes que um processo tenta entrar em sua região crítica ele são impedidas por já existir um outro processo usando o recurso, fazendo o sistema ficar parado esperando que o mesmo tenha acesso a este respectivo recurso.

7.7 SemáforosO conceito de semáforos foi proposto em 1965, sendo apresentado como um mecanismo de sincronização

que permitia implementar, de forma simples, a exclusão mútua sincronização condicional entre processos. O semáforo é uma variável que fica associada a um recurso compartilhado, indicando quando este está sendo

acessado por um outro processo. Ela terá seu valor alterado quando o processo entra e quando sai da região crítica de forma que se um outro processo entrar em sua região critica ele possa checar antes este valor para saber se o recurso esta ou não disponível. Quando o processo tiver seu acesso impedido, ele será colocado em uma fila de espera associada ao semáforo aguardando sua vez de utilizar o recurso. Todos os processos da fila terão acesso ao recurso na ordem de chegada. O semáforo pode ser usado também para implementar sincronizações condicionais. Isto consiste em um processo que necessita ser notificado sobre a ocorrência de um evento. Pode-se usar o semáforo para notificar este processo sobre a ocorrência deste evento.

Outro tipo de semáforo usado é SEMÁFORO CONSUMIDOR onde ele pode informar ao processo se o buffer está cheio ou está vazio.

SEMÁFORO CONTADOR é aquele que notifica os processos sobre o uso dos recursos. Sempre que um processo usa um recurso qualquer, este semáforo é incrementado sempre que um processo liberar um recurso ele será decrementado. Este semáforo é útil para evitar que um processo na região crítica sem que haja recursos disponíveis no sistema.

O uso de semáforos exige do programador muito cuidado, pois qualquer engano pode gerar bugs em seu programa que o levem a falhas de sincronização ocasionando quedas e travamento geral do sistema.

52

Fila de esperad e pro cessos

Pro cesso acessaa reg iã o cr ítica

Processo d eseja en trarna reg ião crítica

DO W N (S= 0)DO W N (S>0)

U P (S) - p ro cesso sa ida região crítica

Libe ra processod a fi la de espe ra

Fig. 7.3 – Utilização do semáforo binário na exclusão mútua

7.8 MonitoresMonitores são mecanismos de sincronização de alto nível que tornam mais simples o desenvolvimento de

aplicações concorrentes. Este conceito foi proposto em 1972. Basicamente, são mecanismos de sincronização compostos de um conjunto de procedimentos, variáveis e

estrutura de dados definidos dentro de um módulo cuja finalidade é a implementação automática da exclusão mútua entre seus procedimentos. Somente um processo pode estar executando um dos procedimentos do monitor em um determinado instante. Toda vez que um processo chamar um destes procedimentos, o monitor verifica se já existe outro processo executando algum procedimento do monitor. Caso exista, o processo fica aguardando a sua vez ate que tenha permissão para executá-lo.

A implementação da exclusão mútua nos monitores é realizada pelo compilador do programa e não mais pelo programador. Para isto ele irá colocar todas as regiões críticas do programa em forma de procedimentos no monitor e o compilador se encarregará de garantir a exclusão mútua destes procedimentos. A comunicação do processo com o monitor passa a ser feita através de chamadas a seus procedimentos e dos parâmetros passados para eles.

Outra característica do monitor é que os processos, quando não puderem acessar estes procedimentos, ficarão aguardando em uma fila de espera e enquanto isto, eles poderão executar outros procedimentos.

Como ele é escrito em uma linguagem de programação, o compilador das outras demais linguagens deverão ser capazes de reconhecê-la e implementá-la. São raras as linguagens que permitem tal implementação criando uma limitação para o uso deste recurso.

D eclaração deva riáveis g lo ba is

Proced im entos

Fila de entra da

Inicia lizaçã ode var iá veis

Proc. 1

Pro c. 2

Pro c. n

Mon

itor

Fig. 7.4 – Estrutura do monitor

53

7.9 Troca de mensagensA troca de mensagens é um mecanismo de comunicação e sincronização entre os processos, implementado

pelo sistema operacional através de duas rotinas do sistema SEND e RECEIVE. A rotina SEND é a responsável pelo envio de uma mensagem para o processo receptor enquanto a rotina RECEIVE por receber a mensagem do processo transmissor. Tais procedimentos mesmo não sendo mutuamente exclusivos permitem a comunicação entre os processos e a sincronização entre eles, pois uma mensagem somente poderá ser lida depois de ter sido enviada e ela somente será envidada após a ocorrência de um evento.

No sistema de troca de mensagens, existe a possibilidade da mensagem se perder. Para isto foi implementado o recurso de que o processo receptor ao recebê-la deverá enviar ao processo transmissor uma mensagem de recebimento. Caso o transmissor não receber esta mensagem em um certo espaço de tempo ele irá retransmitir esta mensagem.

A comunicação entre processos pode ser feita diretamente. Bastando que o processo que deseja enviar uma mensagem enderece explicitamente o nome do receptor. Esta característica chama-se ENDEREÇAMENTO DIRETO e só é permitida à comunicação entre dois processos.

Existe também o ENDEREÇAMENTO INDIRETO que é um mecanismo que consiste no uso de uma área compartilhada, onde as mensagens podem ser colocadas pelo processo transmissor e retiradas por qualquer processo.

Existem duas formas de comunicação entre os processos: COMUNICAÇÃO SINCRONA e COMUNICAÇÃO ASSINCRONA. Uma comunicação é dita Síncrona, quando um processo envia uma mensagem e fica esperando até que o processo receptor leia a mensagem e mande a notificação de recebimento. Uma comunicação assíncrona é aquela em que o processo que envia a mensagem não espera notificação de recebimento.

Processo A Processo B

Fig. 7.5 – Comunicação diretaPro cesso A Processo B

M a ilboxou Port

Fig. 7.6 – Comunicação indireta

7.10 DeadlockO Deadlock existe em qualquer sistema multiprogramável. Dizemos que um processo está em Deadlock

quando este para de responder porque está esperando por um evento que nunca ocorrerá. Esta situação é conseqüência do problema da exclusão mútua. Existem as condições onde o Deadlock irá ocorrer:- Cada recurso só pode estar alocado a um único processo em um determinado instante. (Exclusão mútua)- Um processo além dos recursos já alocados, pode estar esperando por outros recursos. - Um recurso não pode ser liberado de um processo porque outros processos desejam o mesmo recurso (Não-preempção)- Um processo pode ter de esperar por um recurso alocado a outro processo e vice-versa (Espera circular).

54

Recurso 2 Recu rso 1

Pro cesso A

Pro cesso B

Processo Aso licita oRecu rso 2

Recurso 1a loca do aoProcesso A

Recu rso 2a loca do aoProcesso B

Processo Bso licita oRecurso 1

Fig. 7.7 – Espera circular

7.10.1 Prevenção do DeadlockPara prevenir o Deadlock é preciso garantir que uma das quatro condições acima citada nunca ocorra, dentre

as diversas situações já citadas pode ser feito um minucioso trabalho de determinar muito bem que recursos, quais recursos e quando estes recursos deverão ser disponibilizados aos processos.

7.10.2 Detecção de DeadlockEm sistemas que não possuam mecanismos que previnam a ocorrência de deadlocks, é necessário um

esquema de detecção e correção do problema. A Detecção do Deadlock é um mecanismo que determina a existência deste e identifica os recursos envolvidos no problema. Um exemplo deste tipo de detector é o próprio Gerenciador de tarefas do Windows que detecta o aplicativo que parou de responder ao sistema causado, possivelmente, por um deadlock, como podemos ver logo abaixo:

Fig. 7.8 – Exemplo de Deadlock

7.10.3 Correção do DeadlockGeralmente o problema é resolvido eliminando os processos envolvidos e desalojando os recursos para ele já

garantidos. É aquele processo em que você dá um Alt+Ctrl+Del no Windows e aparece uma janela informando o aplicativo que não responde. Este aplicativo pode estar em um processo de Deadlock, neste caso você manda finalizar o aplicativo e tudo voltará ao normal. Muitas vezes este mecanismo não resolve e pelo contrário gera novos problemas. Se você finalizar um processo que esteja intimamente envolvido com o sistema operacional ou que esteja usando recursos de baixo nível do mesmo, você poderá vir a deixá-lo instável ou travado.

55

Abaixo vemos a caixa de dialogo do Windows que tentará fechar o processo que pode estar parado por falta de comunicação com o sistema.

Fig. 7.9 – Correção do Deadlock

O problema do Deadlock é um problema que tende a tornar-se mais critico à medida que os sistemas operacionais evoluem no sentido de implementar o paralelismo e permitir a alocação dinâmica de um numero maior de recursos e a execução de um numero maior de processos simultaneamente. Os usuários sentem muita saudade dos computadores que rodavam o DOS nos bons tempos quando quase não davam problemas. Mas é bom lembrar que o DOS era um sistema operacional monotarefa e monousuário onde praticamente tínhamos apenas um único processo rodando de cada vez. Neste caso não existiam os problemas que um ambiente multitarefa e multiusuário tem hoje. Todos os recursos do sistema estavam exclusivamente disponíveis para aquele processo e, portanto ele tinha total e plena liberdade de fazer com estes o que bem entendia.

Hoje os sistemas operacionais são mais complexos rodando em maquinas mais críticas devido à velocidade de processamento tendo um maior numero de aplicações que rodam simultaneamente e demandando praticamente todos os recursos do sistema ao mesmo tempo. Muitos destes programas trabalham não só com um, mas com vários processos simultaneamente o que aumentam as chances de colisões entre eles ou com os recursos do sistema.

56