Embed Size (px)
Citation preview
Overhead e Processamento Útil.....................................................................................2Projeto de Software.........................................................................................................2
Sistema Micro-Kernel...................................................................................................2História.............................................................................................................................3
Primeiro Sistema Operacional.....................................................................................3Primeiros Computadores Sem Sistema Operacional...........................................3Primeiros Problemas Levantados..........................................................................4Análise microscópia do uso da CPU......................................................................5
Multiprogramação...........................................................................................................5Como compartilhar?.....................................................................................................6Quando e como o SO é chamado?...............................................................................7
Mecanismos de Interrupção...........................................................................................7Tipos de Interrupção....................................................................................................7
Se a CPU não vai buscar a próxima instrução, o que ela vai fazer?...................8Pq o PC tem que ser guardado em duas etapas?..................................................8
CPU – Modos de Operação.............................................................................................8O que a CPU faz?.........................................................................................................8O que o SO faz?............................................................................................................9Mudando o Hardware................................................................................................10
Tratamento com vetor de interrupção................................................................11Tipos de Sistemas Operacionais...................................................................................12
1. Batch (Throughput)................................................................................................122. Time-Sharing (Throughput + Tempo de Resposta)..............................................123. OLTP (On-line Transaction Processing)..............................................................134. Tempo-real (sem throughput, multiprogramação p/ chamar + prioritário)........135. SO de rede...............................................................................................................14
Cluster de computadores..............................................................................................14Gerente de Processos.....................................................................................................15
Código Reentrante......................................................................................................15Criação Dinâmica de Processos.................................................................................15
Processamento Paralelo x Processamento Concorrente....................................16Criação de um processo:.......................................................................................16Processos x Threads..............................................................................................17
Aplicação.............................................................................................................17Criação de Threads ou Processos........................................................................18
Criação de Processos..................................................................................................18Requisição do usuário (interrupção de hardware).............................................18Requisição dinâmica de um processo (em tempo de execução, interrupção por software).................................................................................................................18Requisição de Processo p/ criação de thread......................................................18
Fila de BCP.................................................................................................................19Estados....................................................................................................................20Término de um processo.......................................................................................20
Sistema Multiprogramado..........................................................................................20Arquiteturas Paralelas................................................................................................21
Multiprocessadores................................................................................................21Multicomputadores...............................................................................................22
Programação Paralela................................................................................................22Modelo de Programação com Memória Compartilhada...................................23
Double Buffering.................................................................................................23
1
Exclusão Mútua...................................................................................................24Condições de corrida.......................................................................................24Exclusão mútua com flags...............................................................................25Da arquitetura IBM, solução de hardware: instrução de máquina:.................27Semáforo..........................................................................................................27
Exclusão Mútua...........................................................................................28Sincronismo.................................................................................................28Exclusão Mútua + Sincronismo..................................................................29
Monitores.........................................................................................................29Exclusão mútua...........................................................................................30Sincronismo.................................................................................................31Exclusão Mútua + Sincronismo..................................................................32
Modelo de Programação com Troca de mensagem............................................33Sincronismo.........................................................................................................33Endereçamento....................................................................................................34
Overhead e Processamento ÚtilO SO tem que ter auto-desempenho. Não dá pra vc ficar esperando o SO fazer a tarefa dele. O que o SO gasta com ele mesmo, é gasto extra, não é processamento útil.. É o que chamamos de Overhead. Processamento útil é das aplicações.
Perguntas de prova: Qual o problema da técnica tal? – Overhead Qual o overhead da solução? Pq o overhead é alto? O que está causando?
Overhead é o foco principal do projeto de um SO. Se o overhead for alto o usuário não vai querer usar.
Projeto de SoftwareO projeto de um software como um SO é um projeto enorme, cheio de funcionalidades. Precisa de tempo para ser depurado.O Linux veio num caminho totalmente diferente da Microsoft. Ele foi sendo melhorado aos poucos e ficando cada vez mais robusto. O pessoal se preocupou primeiro com o núcleo do que com a interface.Tanto o Windows quanto a Microsoft partem da filosofia de um Sistema Monolítico. O outro tipo de filosofia que vem em contraponto ao monolítico é o Sistema Micro-Kernel. A idéia deste foi baseada no princípio que tornou o Linux um sistema tão robusto, tão cheio de funcionalidade, radicalizando essa idéia.
Sistema Micro-KernelO Sistema Micro-Kelnel funciona da seguinte forma: Eu tenho o hardware e o núcleo, o meu Kernel. Essa é a única parte do SO que roda como um SO. O resto do SO roda como se fossem processos do usuário. Por isso o SO ficou reduzido a um micro-kernel. Qual a vantagem disso?
2
Eu posso tirar o gerenciador de E/S, por exemplo, e colocar o meu. É mais flexível. No monolítico, tenho que recompilar todo o SO. Tenho que entrar no pacote, entendê-lo, mexer no código e recompilar o sistema. DesvantagemNo Sistema Micro-Kernel as camadas (os módulos de ambiente operacional) têm que se comunicar com mensagens explícitas de um para outro. O que torna o sistema mais lento. Pois a estrutura interna do SO está no núcleo, e o usuário vai e mexe na estrutura de dados do SO. Então eu tenho que garantir a segurança toda do núcleo, e tudo que eu preciso de segurança tem que estar dentro do núcleo. Então muitas vezes um cara precisa alterar uma tabela, ele tem que mandar uma mensagem pro núcleo, e o núcleo ir lá alterar a tabela.No Monolítico o modo de um falar com o outro, é chamada de sub-rotina, é um jump dentro de um programa em baixo nível. Aqui, a tabela é compartilhada, o módulo de memória vai lá e altera a tabela.Sistema de Tempo RealO QNX é eficiente para sistema de tempo real, com arquitetura micro-kernel, se as camadas forem extremamente leves. Não precisa de um sistema de arquivos, por exemplo, que tem uma estrutura de diretórios em árvore, onde um filho pode ligar com o pai, tem que tratar todas essas questões de sistemas de arquivos. O gerente de memória tem que tratar se tem memória virtual, então tem que gerenciar as páginas, tem que ter uma política de substituição de páginas, baseado num sistema que vai atender a uma quantidade enorme de usuários que estão pendurados naquela máquina. Mas o sistema de tempo real é simplificado, vai rodar somente alguns processos em que nenhum usuário vai entrar na máquina, são processos industriais, outras máquinas que vão se comunicar com ele. Não vai rodar um sistema multiusuário como o Linux.Em um sistema de tempo real, não há a preocupação em ser justo com todo mundo, em compartilhar a memória, dividir os recursos. A preocupação é: chegou alguém mais prioritário? Não interessa a divisão de recursos, é tudo pra ele.Não necessariamente o sistema micro-kernel é melhor para tempo real.
História
Primeiro Sistema OperacionalComo as coisas evoluíram?Como chegamos às funcionalidade que temos hoje em dia?Para entender, temos que começar lá do princípio. Como é que começou a idéia do Sistema Operacional.
Primeiros Computadores Sem Sistema Operacional
Tínhamos um esquema parecido com o Z80. Faz um programinha, carrega na memória, coloca endereço no PC, etc... O que existia naquela época era a mesma história, só que o operador era quem fazia isso, só que com os programas dos diversos usuários.
Então, por exemplo, o operador recebia um programa de uma leitora de cartões, não tinha terminal, nem teclado na época, ia lá, apertava algum botões, dava alguns comandos pra que o programa pudesse ser carregado na memória e os valores dentro
3
dos registradores. O programa rodava na máquina, quando saía, a máquina piscava suas luzes, e era, então, a vez de outro, e assim por diante.
Primeiros Problemas Levantados
Primeiros problemas levantados pelo pessoal na época. Erro de ExecuçãoColocava o programa pra rodar, e se desse um erro no meio do caminho? Acendia uma luz vermelha, por exemplo, e o operador ia lá e avisava o programador. Como o programador vai saber o que realmente aconteceu? Muitas vezes o que acontecia era que o operador tinha que dar um dump da memória. Era um relatório que baixava tudo que estava escrito na memória. E o programador tinha que ler tudo pra saber o que aconteceu. Difícil debugar.
Computador OciosoPor exemplo, se o operador saísse pra almoçar. Se a máquina dependesse de alguma função dele, ela ficava ociosa. O computador era dependente da figura do operador, que pode falhar, pode ficar doente. E mais, o operador era uma figura extremamente especializada e ter um profissional assim é caro.
Dispositivos de Entrada e SaídaNovo dispositivo (fita muito melhor). Tinha que reprogramar toda a entrada e saída do programa para o novo dispositivo.
Daí surgiu a idéia de um sistema que ficava rodando e quando tivesse interrupção, analisava o problema. Saía mensagem de erro num cartão, por exemplo. Quando acabasse uma execução, esse programinha pega o próximo e coloca pra rodar, sem precisar do operador. E acoplado a esse programinha, rotinas básicas de acesso a dispositivos. Então, se eu precisar de acesso a um dispositivo, basta chamar essa rotina, não precisa reprogramar. Surgiu o primeiro SO.
O primeiro SO tinha 3 funções:
Sequenciamento de tarefas (jobs)
Desempenho, não fica ociosa. Quando programa acabava, o SO colocava imediatamente outro programa pra rodar. O operador manda um lote de tarefas.
Tratamento de erro de execução
Identificar o problema, o erro de execução, e falar para o usuário. E coloca outro pra rodar.
E/S independente de dispositivo
Rotina de cada dispositivo ficava residente na memória do SO. O programador só tinha que chamar essa rotina, pede ao SO para falar com o dispositivo. Programa independente das características físicas do dispositivo. O SO tem pronto dentro dele os programinhas que falam com o dispositivo.
4
Job: define um trabalho que vc passa ao SO. Conjunto de tarefas que vc submete através da leitora de cartões, p. exemplo. Não interativo. Envelopa as tarefas pedidas dentro do job. Operador alimenta uma vez.
O objetivo do primeiro SO era deixar a máquina trabalhando o tempo todo, sem ociosidade. (menos dependente do operador). Pois o computador custava milhões de dólares.
O SO é a primeira coisa que á carregada na máquina. O tempo todo que a máquina estiver ligada, ele fica na memória. E vai executar quando houver um pedido de entrada e saída ou quando acontecer um erro ou quando um job terminar.
Análise microscópia do uso da CPU
A CPU executava durante um determinado intervalo de tempo as intruções da CPU. Depois, a CPU ficava um bom tempo ociosa esperando por entrada e saída, depois executava mais intruções da CPU, e assim por diante.
Viu-se que esse tipo de comportamento era +ou- típico dos programas. O gráfico diz que a CPU fica muito tempo ociosa esperando E/S. Por quê? Porque E/S é muito mais lento, pq dependem de operações mecânicas.
Fazer E/S = Falar com um dispositivo. Simples mas demorado.
MultiprogramaçãoPassa a tarefa de E/S pra outro processador extremamente simplificado, que não sabe fazer contas, operação de ponto flutuante ou desvio. A única função dele é mandar comandos pra um dispositivo.
Vários programas ativos compartilham o uso da mesma máquina ao mesmo tempo. A CPU, enquanto espera E/S para Job 1, por exemplo, procura outro Job (Job 2).
Todos os jobs ativos compartilhando os recursos da máquina (CPU, dispositivos de entrada e saída, e memória)
t
CPU CPU CPU CPUE/S E/S E/S E/S
t
CPUJ1 J2 J3 J4 J5 J1
E/S
5
Surgiu o conceito de Multiprogramação. Surgiu no ambiente sem interatividade.
Na hora que vc inclui esse conceito dentro do sistema operacional, surgem questões a serem resolvidas pelo SO. Agora tem que decidir como os programas vão ficar na memória, onde eles vão ficar, na CPU, quem vem na frente. CPU ficou livre, quem vai colocar. Entrada e saída, compartilhar mesmo dispositivo.
Quando surgiu o conceito de interatividade, aí a multiprogramação passou a ser necessária. Pois vários usuários ligados interagindo com a máquina, eu preciso atender a todos em um tempo pequeno.
Como compartilhar?Problemas de gerência de dispositivo. Todos os pedidos ativos, o SO vai lá, atende um, depois o outro, depois o outro... num determinado tempo. O SO tem que ter um mecanismo que garanta tempo de resposta pra todos.
Surgiu o dispositivo relógio de tempo real, fora da CPU, responsável por gerar interrupções na CPU em determinados intervalos de tempo. Então CPU coloca SO pra rodar. Aí o SO decide quem vai colocar pra rodar, assim todo mundo é atendido.
Sistema Monoprogramado é o contrário de sistema multiprogramado.
Com o sistema multiprogramado, inclui diversas complexidades no sistema, não é só ajeitar a fila de quem vai usar a CPU. Tem que ter gerência de memória, tem que gerenciar como vai carregar as coisas na memória, e garantir que um não vai afetar a área do outro. Como vai armazenar os aquivos em disco.
Boa parte da teoria dos SO surgiu do que a gente chama de Mainframe (Computador gigantesco com uma quantidade enorme de usuários fazendo requisições a ele). Esse foi o modelo inicial de computação para o qual os problemas que a multiprogramação inclui foram sendo resolvidos.
A questão da multiprogramação inclui no sistema esse conceito de compartilhar a máquina entre diversos usuários e de ter o SO como gerente dos recursos dessa máquina.
Quando e como o SO é chamado?O SO só executa quando há uma interrupção. Não executa o tempo todo, não é processamento útil.
CPU
RTR
6
Então eu estou dividindo a máquina entre vários usuários, vários programas e na hora em que o SO é necessário ocorre uma interrupção, e na interrupção o SO roda.
Pq o meu programa não pode chamar o SO como chamada de subrotina? Pq tem que existir uma interrupção? Pq a CPU não saberia que o SO começou a rodar.
E pq a CPU deve saber que entrou o SO? Por causa da questão de privilégio. O SO deve ter alguns privilégios que os usuários não têm. Assim diferencia o que o SO pode fazer e o usuário não pode.
Mecanismos de Interrupção
Busca InstruçãoDecodificaBusca operandoExecuta
A interrupção existe para quebrar o ciclo acima, o ciclo da CPU. Em vez de buscar instrução, a CPU vai fazer outra coisa.
O que pode causar uma interrupção?
Tipos de InterrupçãoPOR SOFTWARE POR HARDWARE
Instrução para chamada ao SO (se não tiver SO, pára a execução)
Erro de execução
Quando um dispositivo gera um sinal que vem pela porta de interrupção. (fisicamente conectado)
Dispositivo de E/S
Relógio de tempo real
Outra CPU
Quando a interrupção é de software a quebra é sempre onde está indicando a imagem. A interrupção por hardware pode chegar a qualquer momento, mas espera e só quebra no final do ciclo. Toda instrução de máquina é atômica, sempre quebra no mesmo lugar, a interrupção só vai chegar no ciclo seguinte, por causa do ciclo de clock. As interrupções por Hardware são as únicas que podem ser mascaradas (ignorar interrupção, a CPU desabilita interrupção).
7
Se a CPU não vai buscar a próxima instrução, o que ela vai fazer?
Colocar o SO pra rodar. No pto em que ele é chamado, descobrir o que ele tem que fazer. Em termos de hardware, colocar o SO pra rodar é
A CPU guarda o conteúdo do PC na memória em uma posição de memória reservada, chamada de OLD PSW. Guarda a posição de memória em que parou o programa do usuário.
A CPU coloca no PC o endereço do SO. Qual é o endereço do SO? O que se pode fazer é, reservar uma posição de memória (NEW PSW) e toda vez que a CPU for interrompida, ela carrega o conteúdo desse endereço de memória dentro do PC. Quem vai escrever o endereço dele, é o próprio SO quando for inicializado. Não é um registrador na CPU, pq é muito caro, só vai ser lido uma vez a cada interrupção.
NEW PSW = guarda a posição do SO. Nenhum programa, senão o SO, pode acessar essa posição de memória. Quando ocorre uma interrupção a CPU carrega o conteúdo do NEW PSW no PC.
Ou seja, salvar o valor do PC acontece em 2 etapas. Por Hardware (guarda o conteúdo do PC em OLD PSW) e por software (SO reserva local para guardar o conteúdo do OLD PSW).
O SO aloca memória para cada processo. São vários registros que são chamados de BCP (Bloco de Controle de Processo). Como se fosse a ficha de cada processo dentro do SO, que guarda os dados do processo, pra quando o processo voltar. No BCP é guardado o valor do PC quando o SO é chamado.
Pq o PC tem que ser guardado em duas etapas?
Pq eu não posso fazer só por hardware. Pq? Pq o hardware não tem como reservar em hardware posições específicas para cada processo. E o SO tb não pode fazer sozinho, pq pra ele rodar, ele apaga o PC. Então, um precisa da ajuda do outro.
CPU – Modos de Operação Modo usuário Modo Supervisor
Pois o SO tem privilégios (pode fazer instruções privilegiadas) que o usuário não tem.
Os modos de operação criam o conceito de privilégio. Existe um sub-set de instruções privilegiadas, que só o SO pode executar. Ex.: Alterar o flag que marca o modo de execução, rodar o disco, mover cabeça de disco, Store new psw.
O que a CPU faz? 1. Desabilita interrupção2. Seta modo supervisor3. (OLD PSW) PC4. PC (NEW PSW)
Se houver interrupções externas, mascara interrupções.
8
Pode ter um dispositivo do hardware que acumule os sinais de interrupção e fique mandando pra CPU ou reenviando pra CPU.
Nos SOs modernos, que tem um monte de funcionalidades, rodar o tempo todo com interrupções desabilidatas, perde-se muita interrupção, e às vezes, interrupções importantes.
O que os SOs modernos fazem? Depois que SO entrou, salvou o que tinha que salvar, ele reabilita a interrupção e permite que ele mesmo seja interrompido, num esquema de prioridade de interrupções. Vc prioriza as interrupções e só atende a mais prioritária.
Então, por exemplo, vc estava tratando uma interrupção da impressora, aí chegou uma interrupção do disco, que vc considera mais prioritária que da impressora. O que vc faz? Salva seu tratamento da impressora e começa a tratar o disco, depois vc retorna pra lá, como um processo, só que sempre em modo supervisor.
Então o momento de reabilitar as interrupções é uma decisão de projeto do SO. Quanto mais cedo vc reabilitar, menos interrupções são perdidas. Então, logo depois de salvar, o SO já reabilita as interrupções.
Quem desabilita as interrupções é a CPU, ela faz isso sozinha, sem instrução nenhuma, de ninguém. O hardware tá pronto pra fazer isso.
O SO não pode desabilitar interrupções, só habilitar?
O que o SO faz?Ponto de vista do projetista de SO:Como funciona o núcleo de um SO. O núcleo é chamado quando há interrupção. (Parte mais interna do SO)Funcionalidades do núcleo:
1. Salvar conteúdo da OLD PSW no BCP (Bloco de Controle de Processo) referente ao processo que foi interrompido.
2. Salvar o contexto do processo. Conteúdo dos registradores da CPU (no BCP). Não precisa salvar IR. (Pq depois pode entrar outro processo e apagar aquele conteúdo) Quais registradores compõem o contexto? Não dá pra economizar, salva tudo. Registradores de propósito geral não dá pra saber se o programa do usuário usou ou não. O IR não precisa pq a instrução que está lá dentro é o que já foi executado. Quando o processo voltar ele vai voltar com exatamente os valores que estavam dentro da CPU.;
3. Reabilitar interrupção (normalmente a partir daqui é possível reabilitar as interrupções, mas depende do SO);
4. Identificar o tipo de interrupção (descobrir pq ele foi chamado) [A CPU indica ao SO. Flags (CPU cria vetor de flags com esses flagas ligados ao flag de tipo de interrupção que aconteceu) da CPU indicam o tipo de interrupção. Na arq. IBM coloca no próprio PSW.]; (No caso de tratamento com vetor de interrupções p.10 , apenas trata a interrupção).
5. Chamar rotina de tratamento de interrupções em 1º nível (faz parte do núcleo do SO, se vai chamar as outras funções, aí não é mais o núcleo). (O SO tem, pra cada tipo de interrupção, uma rotininha que trata aquele tipo de interrupção) (Em 1º nível pq essa rotina pra tratar interrupção
9
pode precisar chamar os outros módulos do SO, pode ser que seja uma interrupção de disco, de algum problema de gravar arquivo, aí pode ser que precise do gerente de E/S, pra saber onde é que vai colocar aquele bloco, mexer em alguma posição de diretório) (Então a rotina de 1º nível é a que faz o tratamento da interrupção e que pode ser que precise chamar as outras camadas do SO num esquema monolítico. Pode ser que não precise chamar outra camada, ou tenha que chamar várias camadas);
6. Pega o 1º processo da fila pra executar;7. Restaura na CPU o contexto do processo escolhido;8. Seta pra modo usuário e Restaura o valor do PC (Pode ser uma instrução
de máquina, ou não)
A primeira vez que o processo roda. Que tipo de interrupção vai chegar pro SO criar um processo? Interrupção de dispositivo de E/S. (dois cliques, p. Exemplo).
1. SO cria uma BCP (resto do contexto é lixo, não intereça)2. Carrega o código do programa na memória3. Aloca uma área de dados pro processo. (p. 15) 4. Guarda endereço inicial na BCP 5. Carrega contexto do processo pela 1ª vez na CPU
Pra não mover os lixos dos registradores, colocaria-se um IF dentro do núcleo, mas quase nunca é a 1ª vez, vai ficar fazendo sempre o IF a toda interrupção. Não vai ser mais eficiente. Evitar um IF no núcleo é muito importante.
Como faz pra carregar o SO pela 1ª vez? Quando vc monta seu computador, vc vai montar um hardware próprio para inicializar o SO. É como se eu tivesse um programinha, já programado, numa memoriazinha (EPROM, etc) e a máquina, quando liga, executa esse programinha, que diz o que o hardware tem que fazer pra inicializar o SO. Vai no disco, trilha zero, pega o que está lá. Que á a parte do SO pra ele se bootar.
Mudando o HardwareVamos olhar pro trecho do núcleo do SO: identificar o tipo de interrupção e chamar a rotina de interrupção. O que seria isso em termos de código?
Algo como
case interrupção1, call RTI1 e assim por diante
BCPint prioridadeint end. Mem.int PCint ACCdouble RPF1double RPF2int R1
BCP = um registro
SO cria BCP: dá new nessa estrutura. Cria uma área na memória com esse tamanho.
RPF (registrador de pto flutuante)
10
Quero incluir no meu sistema um novo tipo de interrupção. O que eu tenho que fazer?
Reescrever essa parte do núcleo, colocar minha interrupção nova e recompilar o núcleo do SO. Embora muito simples, esse sistema é pouco flexível por ter que reescrever o sistema e recompilar o SO.
Tratamento com vetor de interrupção
Pra resolver este problema os projetistas de hardware propuseram um outro mecanismo de interrupção. Ele faz o seguinte, aqui está a minha memória:
Em vez de uma só NEW PSW, eu posso ter um vetor de NEW PSW (NP1, NP2, NP3...) onde o endereço que eu tenho aqui dentro é o endereço que trata a rotina 1, 2, 3 ...
Lá no hardware,
PC new PSW[i] : coloca nova posição de NP
Escreve rotina
O hardware desvia p/ rotina de interrupção que está no endereço &RTIi
Como, um programa?
Ou seja, em vez de eu ter uma posição com o endereço do SO, eu já tenho o endereço da rotina que trata aquela interrupção. Então o SO não tem que identificar o tipo de interrupção e desviar pra rotina, ele já está na rotina que trata aquele tipo de interrupção.
A rotina vai ter que salvar contexto, 1ª coisa que faz,
trata a interrupção e
restaura contexto.
Qual a diferença? Eu já vou direto
&RTI1
&RTI2
&RTI3
&RTI4
NP1
NP2
NP3
NP4
OP Vetor de Interrupção
RTI = rotina de tratamento de interrupção
11
Qual a vantagem? A flexibilidade de incluir novas interrupções, eu não tenho que recompilar o SO. Basta criar uma nova posição, habilitar essa nova posição, escrever minha rotina de tratamento e colocá-la na memória. O próprio hardware que está desviando pra rotina que trata aquela interrupção.
ATENÇÃO:
O Vetor de NEW PSW é definido pra CPU, o projetista de SO não tem opção, não tem escolha.
É a CPU que, ou vai carregar um endereço só, ou um vetor de interrupções.
Tipos de Sistemas OperacionaisMuitos SOs têm características diferentes, de acordo com a máquina ou a instalação para qual ele está servindo.
1. Batch (Throughput)
Não há interação com o usuário. Vc faz o pedido de execução ou de tarefas, envia um lote de jobs ao sistema. Processamento em lote de jobs. Ao final do lote o sistema dá a resposta.
Tem sentido multiprogramação (outro processador fazendo E/S, adiantando o processo de outros jobs). Mas não tem sentido a multiprogramação dar fatia de tempo, não tem usuário.
Foco no desempenho do SO: throughput (quantidade de trabalho por unidade de tempo) Ex.: jobs/hora
2. Time-Sharing (Throughput + Tempo de Resposta)
Foco: compartilhamento do tempo com os usuários. O projetista do SO continua tendo que se preocupar com throughput, mas tem que se preocupar também em dar tempo de resposta razoável. Cada um vai ter um time slice (fatia de tempo dentro da CPU).
Hardware cada vez maiores para suportar mais usuários (terminais burros, nenhuma capacidade de processamento) pendurados, fazendo pedidos online com a máquina. Surgiram os Mainframes.
12
3. OLTP (On-line Transaction Processing)Parecido com o time-sharing, mas tem processamento de transações. Transação é usada para acesso a banco de dados.
Única coisa que faz é acessar BD. Ex.: Sistema Bancário.
Diferença de Time-Sharing para OLTP: Se o foco é BD, o projetista do SO tem que prover mecanismo muito eficiente de E/S.
Ex.: Cache de disco: deixa na memória principal uma parte dos dados do disco. Os dados vão ficar mais próximos do processador. É mais rápido acessar a mem. que o disco, e o próprio SO substitui os dados da cache pro disco. O sistema de cache de disco tem que estar intimamente integrado ao Sistema Gerenciador de BD.
A fatia de tempo num sistema OLTP, o SO descobre qual o custo de uma transação mínima no BD, por exemplo, ler registro, então ele define que sua fatia de tempo vai ser o suficiente pra se fazer uma transação mínima no BD.
Balanceia os 2 objetivos: throughput e tempo de resposta. Ex.: Aula de dúvida com 1000 alunos. Quanto mais gente, maior throughput. Quanto menos gente, melhor o tempo de resposta. Pra balancear, quantos alunos estão entrando enquanto o tempo de resposta está razoável.
4. Tempo-real (sem throughput, multiprogramação p/ chamar + prioritário)Tempo de resposta crítico. Hardware recebe estímulos externos e responde com tempo mínimo. Ex.: SO que controla uma usina nuclear.
Deve ter multiprogramação para chamar o mais prioritário. Não é pra melhorar a utilização da CPU. Chegou interrupção, atender o mais rápido possível. Não interessa throughput (não é rodar mais coisas, é atender num tempo mín). Mas se for simples, com somente um dispositivo, não precisa.
MainframeTerminais burros
13
5. SO de redeOs processadores foram ficando mais baratos. Surgiu processamento distribuído e redes de computadores.
Surgiram as redes cliente-servidor. Uma mesma máquina pode ser cliente de outra se um serviço nela é melhor, e servidor de outra. As máquinas que têm características de hardware específicas oferecem serviçoes p/ outras, por exemplo, impressora.
Como é um SO numa rede?
Um SO em cada computador
Quem controla esses SOs?
Não existe isso. A idéia é sair da centralização, é distribuir. SO local independente que se comunica por mensagem via rede solicitando serviço.
Essa idéia de computação distribuída, eu conscigo crescer o meu parque computacional de uma forma muito simples e barata. Se preciso mais processamenro, compro mais um computador pessoal pra minha rede.
Fazer upgrade num mainframe é muito caro.
Cluster de computadoresNÃO CAI NA PROVA
Conjunto de processadores interconectados que funcionam como se fossem uma máquina única cheia de processadores. Gerar vários processos e depis fazer com que eles se falem pra dar o resultado final. Plataforma mais utilizada para computação de alto-desempenho.
Medição de desempenho é feita por flops (float point operation per second), quantas operações de pontos flutuantes por segundo a máquina faz.
Pq a quantidade de flops é importante? Pq vc comparar arquiteturas com o relógio (clock) não é uma medida justa de comparação, pq eu tenho arquiteturas diferentes muitas vezes, e uma máquina com um clock com uma frequencia maior pode ser uma máquina mais lenta pra minha aplicação pq naquela arquitetura eu gero mais intrução de máquina pra executar o mesmo código. O tempo de execução da aplicação é um dado ruim pra vc que quer comprar a máquina como vc vai saber o tempo de execução da sua aplicação?
SO
SO
SOSO
SO
Rede cliente-servidor
14
Ex.: conjunto de operações de pto flutuante para prever o clima.
Gerente de ProcessosÉ um módulo do sistema operacional que gerencia o conceito de processo. O conceito mais importante que o So cria, pq são os processos que vão solicitar recursos, que vão usar o hardware da máquina.
Processo: Quando um conjunto de instruções é colocado pra executar, ele se torna um processo pro sistema operacional. Pq aquele processo vai pedir recursos de E/S, vai solicitar serviço ao SO, vai usar memória, vai usar CPU.
O programa não, pro SO não interessa, é um monte de bit. Mesmo programa pode gerar vários processos. Vários códigos podem gerar um processo. Por exemplo, seu programa desvia pra um programa diferente, mas o processo é o mesmo.
Ex.de mesmo programa gerando vários processos: Chrome, cada nova aba é um novo processo em execução. No IE não. Editor de texto, vários usuários pedindo pra executar o mesmo programa.
Mesma área de código
Cria várias áreas de dados (BCPs), uma para cada pedido de execução.
Qualquer programa pode ser reentrante?
Não!!!
Código somente leitura pode.
Tem programa que altera seu próprio código dinamicamente (esse não pode). Ou quando tem dados estáticos.
Como garantir que quando vc pedir pra executar um mesmo código, ele vai criar uma outra área de memória?
Seu código tem que estar preparado pra isso, tem que criar dinamicamente uma outra área de dados. Por isso nem todo código pode ser reentrante.
Código ReentranteSO marca que esse programa é reentrante. Não carrega o código mais de uma vez na memória. Se um segundo usuário pedir pra executar o mesmo programa, não carrega o código, cria BCP.Vantagem: Não precisa carregar o programa toda hora, economiza memória logo, pode ter mais processos e, com isso, melhora throughput. Além de ser mais rápido na inicialização.
Criação Dinâmica de ProcessosOutro caso que o mesmo programa gera vários processos.
15
P1 cria P2 para rodar ao mesmo tempo que ele. Pra quê? Aumentar desempenho da aplicação.
Ex.: Processo vai abrir um formulário. Enquanto usuário preenche (E/S) o processo está bloqueado, ativo um outro processo que gera uma animação dentro da página.
Criação dinâmica, em tempo de execução. Processos executam (logicamente) ao mesmo tempo. Fisicamente instruções são de um ou de outro. Logicamente pois 1CPU 1 processo de cada vez em instante de tempo p1 e p2.
Chega interrupção que sai P1 e entra P2. Não tem como prever a ordem de execução das instruções. Quem solicita interrupção?
Para o SO é como se estivesse executando em 2 CPUs virtuais mais lentas que a CPU real.
Processamento Paralelo x Processamento Concorrente
Paralelo: mais de uma CPU.
Concorrente: concorrendo pela mesma CPU. Logicamente, é como se estivessem em paralelo, pois vc não sabe quando um entra e quando um sai. Por não saber se a ordem de execução é como se fossem 2 CPU’s virtuais.
Pro SO, se eu ativei 2 processos ao mesmo tempo tanto faz se hardware vai suportar paralelismo ou concorrência, os processos serão os mesmos.
Quando vc tem uma única CPU, só faz sentido ter processos que vão rodar ao mesmo tempo, se na sua aplicação vc sabe que um processo vai ficar esperando alguma coisa. O outro pode adiantar algum processamento.
Há uma interrupção por software pra criar, e pra rodar P1 e P2, o SO decide.
Criação de um processo:
So foi chamado por uma interrupção
Carrega o código de P1 na memória
P1
P1
P2
Processo filho (P2) roda ao mesmo tempo que o processo pai (P1)
16
Aloca uma área de dados pra P1 (Separa a área em que P1 vai escrever seus dados)
Cria dentro do SO uma BCP pra P1
No meio do código P1 pede pra executar outro processo (P2). O que o SO faz?
O código de P2 não preciso carregar pois está dentro do mesmo código (uma subrotina dento do código).
Cria nova BCP e nova área de dados (processos têm área de dados diferentes).
Processos x Threads
PROCESSOS: podem compartilhar dados, mas vc programador tem que explicitamente definir essa área de dados compartilhada. Com threads não.
THREAD: compartilham mesma área de dados. Não cria novo espaço de endereçamento. Vantagem: economiza memória. Grande vantagem: mais simples proprogramador pois eles compartilham por default, não precisa decidir isso no código. Mas pode atrapalhar pq vc não pode ler um dado que o outro está lendo. Outro benefício muito grande, em termos de hardware: Tem a CPU e a Cache, quando tira a T1 e carrega a T2, a grde vantagem é que aproveita os mesmos dados da cache.
Os dados criados pela thread são dados locais, os dados criados antes da thread ser criada, são todos compartilhados.
P1 P2: troca de contexto (recarrega cache com dados de P2)
T1 T2: mantém dados na cache. Troca de uma pra outra de forma muito mais barata, pois tem praticamente todos os dados dentro da thread.
A decisão de abrir processo ou threads depende do programador pois
os dados já estão compartilhados por default p/ threads, isso pode ser mais fácil ou mais difícil. Mais fácil no sentido q vc não tem que gerenciar área compartilhada, mais difícil pq é tudo compartilhado, tem que controlar o acesso.
Além disso vc tem que saber em que arquitetura vc está executando suas threads ou processos. Suponha uma arquitetura paralela, várias CPU’s. Então proc. Ou threads podem ser distribuidas pelas CPUs e rodar ao mesmo tempo. Se as CPU’s compartilham uma mem. principal, então eu posso colocar threads em CPU’s diferentes, senão não posso, tenho que criar processo.
AplicaçãoSe no meu código eu decidi ativar threads ou processos para executar ao mesmo tempo:
17
Se estou fazendo isso pq minha arquitetura tem mais de uma CPU, significa que estou usando programação paralela p/ obter mais desempenho.
Se eu não tenho arquitetura paralela. Então pra q eu quero criar procesos ou threads? Quando um vai ficar bloqueado.
Criação de Threads ou Processoscreate-process (nome_rotina)create-thread (nome_rotina)
Criação de Processos
Requisição do usuário (interrupção de hardware)
o Carrega área de código na mem. principalo Aloca área de dadoso Cria BCP
Requisição dinâmica de um processo (em tempo de execução, interrupção por software)
o Aloca área de dadoso Cria BCP
Requisição de Processo p/ criação de thread
o Criar BCP
Bloco de controle de processo (BCP)
P1
P1
P1 P2 P3
fork
join
18
Enereço inicial
Área de contexto
Tamanho do código (pra qd fazer realocação na mem., mover o programa de lugar, saber o quanto ocupa na mem.)
End. Inicial da área de dados
Identificação
Prioridade
Etc...
Fila de BCPSO vai escolher processo pra ganhar a CPU. Ex.: O de maior prioridade. O SO vai percorrer todaas BCP’s e ver quem tem maior prioridade.
Então falta organizar as BCP.
SO organiza BCP’s em fila para qd for tomar a decisão para escolher o processo pra ganhar a CPU, basear-se no tipo de recurso que o processo está esperando. Pega 1º da fila.
Para formar fila, classifica o processo pelo estado dele (3 estados diferentes)
Kill = terminar na mão
Término
Início
Pronto
Execução
Bloqueado
Kill
Kill
Máquina de Estado
19
Estados
Pronto = esperando a sua vez de entrar na CPU. Tem uma fila de prontos de acordo com a prioridade. O 1º da fila de prontos (fila de BCP’s) é o que está em execução, não preciso tirar da fila de prontos.
Execução = rodando na CPU
Bloqueado = esperando algum evendo, p. Ex.: E/S. Só ficam em fila os processos que estão esperando o mesmo recurso.
Quando vc dá um delay new, o SO é chamado, coloca seu processo bloqueado até tal hora. Soma new com a hora corrente (x). Quando chegar a hora x + new, coloca pra rodar. Como o SO vai saber que aquela hora aconteceu? Ele é interrompito a cada fatia de tempo. Ele tem noção de tempo real.
Execução Pronto quando acaba o time slice, por exemplo.
Bloqueado Pronto: Ex, um disco, grea interrupção para avisar que já acabou
Término de um processo
Desaloca memória principal (área de código e área de dados) Em que situações isso não acontece? não acontece quando é uma thread (dados continuam na memória), quando é um processo filho. Ou quando é um processo reentrante (quando tem vários processos na memória. Quando o último terminar, aí desaloco).
Libera área do BCP (retirando da fila, caso necessário)
Tabela de alocação: Pode deixar um programa na mem. sem processo. Quando pedir pra esecutar denovo, verifica se alguém utilizaou ou não. (desalocar código, deixa como livre, se ninguém ocupou, já está carregado, se não, carrega denovo)
Sistema MultiprogramadoNum sistema multiprogramado, todo mundo que está pronto tem que estar com o código carregado na memória.
Como o SO garante que um processo não vai afetar a área de memória de outro processo? O SO não está rodando, não controla os acessos à memória. Deve haver um mecanismo de hardware para impedir que a instrução seja realizada.
Pq não chamar o SO a cada acesso a memória? Overhead vai ser enorme.
Qual mecanismo usar? SO guarda limite inferior e limite superior (dois registradores) na hora que carrega o contexto do processo que vai executar.
Em tempo de execução, o que a CPU faz? Antes de pegar o valor e colocar no MAR, testa pra ver se está dentro do limite. Se não estiver, erro de execução, violou proteção
20
de memória. Instrução de acesso e alterações dos registradores de limite só executam em modo supervisor.
Arquiteturas ParalelasArquiteturas que suportam paralelismo.
Arquitetura MIND – cada elemento de processamento (CPUs, cores) executa de forma assíncrona, mesmo com o mesmo código. Cada um com sua velocidade de execução. Pode ser dividida em duas classes principais: Multicomputadores x Multiprocessadores. Programa para um é diferente do programa p/ outro.
Multiprocessadores
Memória compartilhada é diferente de centralizada.
Memória centralizada: Pra todas as CPU’s o custo de acessar qq posição da mem é exatamente o mesmo. Qual o problema? O uso do barramento vira um gargalo de acesso à CPU. Todo mundo espera sua vez de ir à memória.
Daí surgiu o conceito de microprocessador escalável. Cada CPU tem sua memória local. Mem. distribuída, mas incluo um hardware extra que dá a visão de mem. compartilhada. Posso incluir mais CPU e mais mem. sem cair o desempenho do sistema.
Memória distrubuída Mais fácil programar Mais cara (acessar dados de outras CPU’s é muito mais caro, manda msgs e
recebe o dado de volta) Controlador de cache (envia msg pela rede e pede dado que está em outra CPU,
transparente pro programador)
MP
CPU
CPU
Memória centralizada
CPU
21
Multicomputadores
Sem memória compartilhada
Mais difícil programar
Arquitetura mais barata (um conjundo de CPU’s e memórias interconectados por rede)
Programador se preocupa em mandar mensagem. No multiprocessador tá td na memória. Por isso é mais difícil programar pra um multicomputador.
É função do programador enviar dado através de mensagem.
Existe a possibilidade de fazer essa comunicação por software, mas é muito caro, pouco eficiente. Pra simular memória compartilhada.
Diferença pro cluster: é que são vários computadores interligados que funcionam como um único computador com várrias CPU’s. Todo mundo está ali p/ computar em paralelo uma mesma computação.
Problema: Uso do barramento
Programação ParalelaNão importa se eu tenho ou não uma arquitetura paralela para executar minha aplicação. Apenas criando processos que vão executar paralelamente ou concorrentemente.
Modelo de Programação com Memória Compartilhada
Processos em paralelo que podem compartilhar dados.
CPU
Mem
Mem
Mem
CPU CPU
Cache
NUMA
22
Criação de processos e threads
o create_process (nome_da_rotina)
o create_thread (nome_da_rotina)
Terminação
o Wait (n)
Double Buffering
Analisa o que pode fazer ao mesmo tempo pra garantir que só rode ao mesmo tempo processos que são independentes. Abre palarelismo (gets) e volta pra serial (get, copy).
Get(0);For (i = 1, i < n, i++) {
Copy;Create-process (put(i-1));Create-process (get(i));Wait(2);
}Copy;Put(n);
No SO o que existe normalmente na E/S? O SO faz entrada e saída utilizando uma área na memória chamada de buffer de E/S. Significa o seguinte... vc pediu pra ler 1 dado do disco. Ir ao disco é muito caro. Então na hora que ele vai ao disco ele pega um bloco inteiro do disco e traz o bloco pro buffer e deixa lá.
Técnica de double buffering do SO. Suponha que vc vai ler um arquivão enorme do disco. O SO cria 2 buffers de E/S (1 e 2). E como ele faz a cópia dos dados do disco? Joga um segmento S0 do disco no buffer 1 e depois copia no buffer 2. Aí o P1 que está precisando desse disco vai acessar sempre o 2º buffer. Enquanto isso, o SO vai carregando o S1 no buffer 1. Enquanto o processo 1 está consumindo os dados do S0, o SO está adiantando a leitura do disco. Não acontece o copy (cara), o que ele faz é inverter os buffers. Em vez de jogar o S0 pra lá, ele manda o processo consumir do outro.
V1
V2
B1
B2
Get(i)
Copy
Put(i)
23
Exclusão MútuaProver ao programador mecanismos de criar processos que vão executar em paralelo sem ter que voltar para serial pra acessar o dado, mesmo com acesso a dados compartilhados. Garantir que vão funcionar corretamente.
Observador Repórter
Loop Cont = cont+1 Resporta (cont)
Cont = 0
Os dois foram disparados em paralelo. Vão compartilhar dados, os resultados são não determinísticos. Garantir que os trechos de código trabalhem com exclusão mútua.
Pode perder contagem – enquanto tá reportando, tá ocorrendo eventos. Quando acabar, vai zerar.
Condições de corrida (race condictions) – resultado depende do tempo de execução. Como se estivessem apostando uma corrida. Dependendo de quem chegar antes, o resultado é diferente.
O resultado depende do tempo de corrida gera resultados não determinísticos.
Para que o programa não entre em condição de corrida, garantir exclusão mútua de execução do trecho onde há efetivamente compartilhamento de dados (seção crítica). Pq se fizer no código todo, estou voltando pra serial.
Introduzir no código protocolos de entrada e saída. Pergunta se a seção crítica está livre.
Observador Repórter
Protocolo de E Protocolo de E
Loop Cont = cont+1 Resporta (cont)
Protocolo de S Cont = 0
Protocolo de S
O mecanismo de habilitar e desabilitar interrupções pode ser usado pra garantir exclusão mútua pra seções críticas?
Só se os dois estiverem competindo pelo mesmo processador.
24
Exclusão mútua com flags
vez = 0
P0 P1
While (vez=0) do nop; While (vez=1) do nop;
SC0 SC1
vez=1; vez=0;
Problemas:
Perde desempenho, perde paralelismo. Tá segurando por causa da prioridade estática, estaticamente, definiu quem vai usar primeiro, com isso estou diminuindo a possibilidade de paralelismo.
Defini que o P0 vai acessar primeiro a seção crítica. Suponha que P1 chegou primeiro, a seção crítica está livre, ninguém tá usando, mas ele não vai poder entrar pq o P0 ainda não usou.
Ou ainda, o zero começa a executar e quebra no meio, ou até fora da seção crítica. O P1 nunca vai poder utilizar a seção crítica.
Um problema fora da seção crítica não pode causar problema no outro. Com prioridade est[ática causa.
Essa solução garante exclusão mútua, mas com prioridade estática, que diminui muito o desempenho e o paralelismo.
Então, foi criada a seguinte solução que independe de vez, quem chegar 1º, usa:
flag[0] = flag[1] = false
P0 P1
flag[0] = true; flag[1] = true;
while (flag[1]) do nop; while (flag[0]) do nop;
SC1 SC2
flag[0] = false; flag[1] = false;
Problemas:
o Mesmo no mesmo processador, podem ficar no loop eternamente se for interrompido no flag=true., e o outro tb. Os dois setaram pra true.
o Não funciona se os dois chegarem exatamente ao mesmo tempo.
25
Como criar um protocolo decente de E/S? Esse protocolo deve
1. Garantir exclusão mútua
2. Não ter prioridade estática
3. Bloqueio de um processo fora da SC não pode causar o bloqueio de outro processo
4. A decisão sobre a entrada na SC deve ser tomada em tempo finito
flag[0] = flag[1] = false
P0 P1
flag[0] = true; flag[1] = true;
vez=1; vez=0;
while (flag[1] and vez=1) do nop; while (flag[0] and vez=0) do nop;
SC1 SC2
flag[0] = false; flag[1] = false;
Um dos dois valores (de vez) vai ficar. Depende de quem chega ao barramento por último.
Problema:
Só vale pra 2 processos.
Viram que a solução não era trivial por software. A solução foi colocar no hardware.
26
Se todos chegarem ao mesmo tempo, não pode entrar em loop. Deve decidir quem entra.
Da arquitetura IBM, solução de hardware: instrução de máquina:Test-and-set (x)
o Seta x pra true e retorna o valor de x
o Vc passa o endereço de uma posição de memória em uma única instrução de máquina (atômica)
Usando de um jeito alto nível:
var x: Boolean;
x = false;
P0 P1
while (test-and-set(x)) do nop; while (test-and-set(x)) do nop;
SC1 SC2
x = false; x = false;
Problema:
Espera Ocupada
Gasta tempo do processador pra esperar. Quando x=V fica testanto se já é false.
Tem que bloquear processos para acabar com espera ocupada. Melhora o mecanismo de proteger a SC usando SO pra bloquear o processo.
SemáforoTipo de variável
S:semáforo
Só pode fazer em s:
o Inicializar (1 vez só)
o P(S)
o V(S)
P(s)
If s=0 {
bloqueia;
}
27
Se s=1; SC aberta.Se s=0; SC fechada
s=s-1;
V(s)
If (tem processo na fila) {
Ativa processo;
}
s=s+1;
Exclusão Mútua
var s: semáforo;
s = 1;
P0 P1
P(s); P(s);
SC1 SC2
V(s); V(s);
Não dá pra fazer P(s) e V(s) em instrução de máquina pois tem que chamar o SO pra bloquear e ativar.
Tem que executar de forma atômica. O compilador garante a atomicidade de P e V, protegendo com test-and-set.
Mais eficiemte se a SC for grande.
Espera ocupada muito pequena. O que é melhor? Se a SC for muito pequena, melhor espera ocupada ou semáforo? Espera ocupada, pq bloqueio envolve chamar SO, salva contexto, bloqueia... Mas não utiliza test-and-set em alto nível.
Sincronismo
var s: semáforo;
s = 1;
k = 0;
P0 P1 P3
P(s); P(k)
X=4; imprime(x); y=x
V(s); V(k);
Mesmo problema do get copy put p.23.
28
Exclusão Mútua + Sincronismo
Produtores x Consumidores: Considere 2 processos paralelos chamados produtor e consumidor. Estes processos compartilham um buffer de 10 posições. Produtor insere elementos no buffer. Consumidor tira elementos do buffer. Programe uma aplicação utilizando semáforos e considerando que:
1. O acesso ao buffer é feito com exclusão mútua
2. O consumidor não pode retirar elementos se o buffer estiver vazio
3. O produtor não pode inserir elementos se o buffer estiver cheio
P=10;
s=1;
c=0;
P0 P1
P(p); P(c);
P(s); P(s);
SC1 SC2
V(s); V(s);
V(c); V(p);
Se eu tivesse invertido P(s) e P(c), ou seja P(s);
P(c);
Cairia no Deadlock
Segurei a seção crítica com o P(s) e fiquei esperando pelo V(c). Segura o recurso que estou esperando e espera pelo recurso que estou segurando.
Na hora que inverti a ordem dos P’s, eu aimentei o tamanho da seção crítica.
MonitoresMais alto nível para comseguir exclusão mútua e sincronismo.
Idéia de OO. Encapsulamento todo de exclusão mútua e sincronismo em uma classe.
Precursor da orientação a objeto
Exclusão mútua e sincronismo ficam encapsulados em uma classe monitor
o Exclusão Mútua: Qualquer método monitor é executado com exclusão mútua no tempo
o Variáveis de condição
x : condição
x.wait bloqueia o proceso
x.signal libera o processo bloqueado em x
Cria em baixo nível os P’s e V’s.
29
sincronismo
Exclusão mútua
Observador e repórter usando monitores
Observador Repórter
Loop Cont = cont+1 Resporta (cont)
Cont = 0
Teste:monitor
Var cont:int
Procedure observa
Cont = cont + 1;
Procedure reporta
Imprime (cont);
Cont = 0;
Begin
Cont = 0;
End
Observador Repórter
Teste.observa Teste.reporta
Sincronismo
Obs.: Não é seção crítica
P0 P1
30
X = 4 imprime (x)
M1:monitor
Var y:condição
flag:boolean
Procedure bloqueia
If flag = false
y.wait
Procedure libera
y.signal
flag = true
Begin
flag = false
End
P0 P1
X = 4
M1.libera M1.bloqueia
Imprime(x)
Exclusão Mútua + Sincronismo
M3:monitor
Var x:condição
y:condição
31
flag: int
Procedure produz
If (flag = 10)
y.wait
insere
flag = flag + 1
If (cont = 1)
x.signal
Procedure consome
If (flag = 0)
x.wait
retira
flag = flag – 1
if (cont = 0)
y.signal
Begin
flag = 0;
End
Produtor Consumidor
M3.produz M3.consome
Modelo de Programação com Troca de mensagem
Nunca vou poder falar de thread aqui. Não há dado compartilhado, não há memória compartilhada. Não tenho um multiprocessador.
32
Pra evitar ficar dando sinal atoa. Tem que chamar o SO pra bloquear ou liberar, signal ou wait.Logo, essa solução é mais eficiente
Processos se comunicam através de:
SEND (endereço do dado, tamanho, id do processo);
RECEIVE (endereço do dado, tamanho, id do processo);
P0 P1
X = 4 RECEIVE (&Y, 1, P0)
SEND (&X, 1, P1) imprime(Y)
continua, não bloqueia
Não bloqueante. Tem buffer, SO joga no buffer.
Não tem dado compartilhado, não tem seção crítica.
Sincronismo
SEND
SEND não bloqueante
SENDB bloqueante
RECEIVE
RECV bloqueante
RECVNB não bloqueante
Para que eu possa implementar um SEND não bloqueante, o SO tem que implementar um buffer de mensagens. Na hora que deu o SEND, chamou o SO. O SO vai pegar o dado e vai botar num buffer de msgs. Quando o outro processo chegar no RECEIVE, o SO vai transportar o dado do buffer pra este processo.
Com o SEND bloqueante não tem buffer. Eu tenho que ficar parado esperando que o outro processo esteja pronto pra receber, pra então a mensagem ir. Sincronismo mais forte. Um espera pelo outro.
Pra que o uso do RECVNB? Exemplo, dá RECVNB pra ver se alguém me pediu tarefa.
P0 P1
X = 4 RECV (&Y, 1, P0)
SENDB (&X, 1, P1) imprime(Y)
não tem buffer. Espera
o receive. Segura o processo
33
Endereçamento Ponto-a-ponto
Um processo envia pro outro, cada um sabe do outro Difusão
o Broadcast (BCAST (x, 1))Manda pra todos os processos. Como se fossem vários sends.
o Multicast (MCAST (x, 1, grupo))Manda pra um grupo específico
Emissor genéricoRECV (end, tem, ANY_SOURCE)Recebe mensagem de qq um, na msg descobre de quem veio
Não tem um buffer compartilhado, considerendo o buffer no processo Gerente. Não é escalável. Se tiver muitos clientes, o gerente vai virar um gargalo. Desempenho cai.
Produtor Gerente Consumidor
SEND(ok,1,gerente) RECV(dado,1,ANY_SOURCE) SEND(pedido,1,gerente)
RECV(ok,1,gerente) if msg.source=produtor RECV(dado,1,gerente)
If (cont <= 10)
Insere(dado)
Cont = cont+1
SEND (ok,1,produtor)
Prod_preso = false
ELSE
Prod_preso = true
If (cont=1) & (cons_preso)
Retira(dado_R)
SEND(dado_R,1,consumidor)
Cont = cont-1
If msg.source = consumidor
If (cont > 0)
Retira (dado_R)
Cont = cont-1
SEND(dado_R,1,consumidor)
Cons_preso = false
ELSE
Cons_preso = true
If (cont = 9) & (prod_preso)
SEND(ok,1,produtor)
Insere(dado)
Cont = cont+1
34
