Sistema Operacional. Prof. Leonardo Barreto Campos. 1/30

Transcrição

1 Sistema Operacional Prof. Leonardo Barreto Campos 1/30

2 Sumário Introdução Middleware e SO de Rede SO de Rede Processos e Threads Leitura Complementar Bibliografia 2/30

3 Introdução A tarefa de qualquer sistema operacional é fornecer abstrações dos recursos físicos subjacentes processadores, memória, comunicação e mídias de armazenamento. 3/30

4 Introdução Um sistema operacional fornecem ao programador, por exemplo, a abstração de arquivos, em vez de blocos de disco, e soquetes, em vez de acesso direto à rede. Exemplos de Sistemas Operacionais: UNIX (como o Linux e o Mac OS X) Windows (como o XP, o Vista, Windows 8, Windows 10, etc) Sistemas operacionais móveis: Android, ios, BlackBerry OS, Windows Phone, Symbian 4/30

5 Introdução UNIX (como o Linux e o Mac OS X) 5/30

6 Introdução Windows (como o XP, o Vista, Windows 8, Windows 10, etc) 6/30

7 Introdução Sistemas operacionais móveis: Android: 7/30

8 Introdução Sistemas operacionais móveis: ios: 8/30

9 Introdução Sistemas operacionais móveis: Windows Phone: 9/30

10 Introdução Sistemas operacionais móveis: Symbian, webos, Firefox OS, WebOS, brewmp, BlackBerry OS: 10/30

11 Middleware e SO de Rede O UNIX e o Windows são exemplos de sistemas operacionais de rede. Eles têm um recurso de interligação em rede incorporado e, portanto, podem ser usados para acessar recursos remotos. 11/30

12 Middleware e SO de Rede Por outro lado, caso tenhamos um sistema operacional no qual o usuário nunca se preocupasse com o local onde seus programas são executados, ou com a localização de quaisquer recursos. Haveria uma imagem única do sistema. O sistema operacional teria controle sobre todos os nós do sistema e dispararia novos processos de forma transparente, no nó mais conveniente, de acordo com sua política de escalonamento. Um sistema operacional um sistema distribuído assim é dito sistema operacional distribuído. 12/30

13 Middleware e SO de Rede SO s (puramente) distribuídos não existem! É provável que continue assim, por dois motivos principais, são eles: O primeiro é que os usuários têm muito investimento feito em software aplicativo, o qual frequentemente atende a suas necessidades atuais O segundo motivo contra a adoção de sistemas operacionais distribuídos é que os usuários preferem ter certo grau de autonomia em suas máquinas, mesmo em uma empresa muito fechada. 13/30

14 Middleware e SO de Rede A combinação de middleware e sistemas operacionais de rede proporciona tanto um equilíbrio aceitável entre os requisitos de autonomia quanto o acesso aos recursos, transparente com relação à rede. O sistema operacional de rede permite que os usuários executem, de forma independente dos demais, seu processador de textos predileto e outros aplicativos. A camada de middleware permite que eles tirem proveito de serviços distribuídos que se tornem disponíveis para seu sistema operacional. 14/30

15 Middleware e SO de Rede Voltemos um pouco: 15/30

16 Middleware e SO de Rede Combinação perfeita: O SO que está sendo executado em um nó fornece, de acordo com seus recursos de hardware locais, seu próprio conjunto de abstrações para processamento, armazenamento e comunicação. O middleware utiliza essas abstrações para implementar seus mecanismos de invocações remotas entre objetos ou processos nos nós. O objetivo dessa aula, portanto, é examinar o impacto dos mecanismos do SO, em particular, sobre a capacidade do middleware de apresentar compartilhamento de recursos distribuído para os usuários. 16/30

17 SO de Rede Espera-se de um SO de Rede as seguintes funcionalidades: Encapsulamento: eles devem fornecer uma interface de serviço útil para seus recursos isto é, um conjunto de operações que satisfaça as necessidades de seus clientes. Os detalhes, como gerenciamento de memória e dispositivos usados para implementar os recursos, devem ser ocultados dos clientes. Proteção: os recursos exigem proteção contra acessos ilegítimos por exemplo, os arquivos são protegidos contra leitura de usuários sem permissões de leitura e os registradores dos dispositivos de E/S são protegidos contra acessos de processos aplicativos 17/30

18 SO de Rede Espera-se de um SO de Rede as seguintes funcionalidades: Processamento concorrente: os clientes podem compartilhar recursos e acessá-los concorrentemente. Os gerenciadores de recurso são responsáveis pela transparência da concorrência. Comunicação: parâmetros e resultados de operação precisam ser passados por gerenciadores de recursos, via rede ou internamente ao próprio computador. Escalonamento: quando uma operação é invocada, seu processamento deve ser agendado dentro do núcleo ou do servidor. 18/30

19 SO de Rede A Figura mostra as funcionalidades básicas de um SO com que vamos nos preocupar: gerenciamento de processos e threads, gerenciamento de memória e comunicação entre processos no mesmo computador (as divisões horizontais na figura denotam dependências). 19/30

20 Processos e Threads Nos anos 80, foi descoberto que a noção tradicional do sistema operacional, de um processo que executa um único fluxo de execução, era diferente dos requisitos dos sistemas distribuídos: O problema é que o processo tradicional torna complicado e dispendioso o compartilhamento de recursos entre atividades relacionadas. A solução encontrada foi aprimorar a noção de processo, para que ele pudesse ser associado a múltiplas atividades. Atualmente, um processo consiste em um ambiente de execução, junto a uma ou mais threads. 20/30

21 Processos e Threads Diferença entre linha única de execução e Multithread: 21/30

22 Processos e Threads Uma thread é a abstração do sistema operacional de uma atividade (o termo é derivado da frase fio (thread) de execução ). O objetivo principal em se ter múltiplas threads de execução é maximizar o grau de execução concorrente entre operações, permitindo, assim, a sobreposição da computação com operações de entrada e saída, e possibilitando a execução simultânea de atividades em máquinas do tipo multiprocessadores. As threads podem ser criadas e destruídas dinamicamente, conforme necessário. 22/30

23 Processos e Threads Isso pode ser particularmente útil para servidores, em que o processamento simultâneo de requisições de clientes pode reduzir a tendência de criação de gargalos de processamento. 23/30

24 Processos e Threads Arquitetura do conjunto de trabalhadores: Ao ser inicializado, o servidor cria um conjunto fixo de threads trabalhadores para processar os pedidos; O módulo identificado como recepção e enfileiramento é normalmente implementado por uma thread de E/S ; A thread recebe pedidos de um ou mais de soquetes, ou portas, e os coloca em uma fila de pedidos para serem recuperados pelas trabalhadoras; 24/30

25 Processos e Threads Arquitetura thread por pedido: A thread de E/S gera uma nova thread trabalhadora para cada pedido, e esse trabalhador autoterminará quando tiver processado o pedido. Vantagens: as threads não disputam uma fila compartilhada; a thread de E/S pode criar tantos trabalhadoras quantos forem os pedidos pendentes Desvantagem: sobrecarga das operações de criação e destruição de threads 25/30

26 Processos e Threads Arquitetura thread por conexão: Associa uma thread a cada conexão e destrói a thread quando o cliente fecha a conexão. Nesse meio-tempo, o cliente pode fazer vários pedidos pela conexão, destinados a um ou mais objetos remotos. Vantagem: O servidor se beneficia das menores sobrecargas de gerenciamento de thread. Desvantagem: os clientes podem sofrer atrasos quando uma thread trabalhador tem vários pedidos pendentes, mas outra thread não tem trabalho a fazer 26/30

27 Processos e Threads Arquitetura thread por objeto: Associa uma thread a cada objeto remo. Vantagem: O servidor se beneficia das menores sobrecargas de gerenciamento de thread. Desvantagem: os clientes podem sofrer atrasos quando uma thread trabalhador tem vários pedidos pendentes, mas outra thread não tem trabalho a fazer 27/30

28 Processos e Threads Podemos fazer um resumo da comparação entre processos e threads, como segue: Criar uma nova thread dentro de um processo existente é computacionalmente menos oneroso do que criar um processo. O chaveamento para uma thread diferente dentro de um mesmo processo é menos oneroso do que chavear entre threads pertencentes a processos diferentes. As threads dentro de um processo podem compartilhar dados e outros recursos conveniente e eficientemente, em comparação a processos distintos. Porém, além disso, as threads dentro de um processo não são protegidas umas das outras. 28/30

29 Leitura Complementar Link: 29/30

30 Bibliografia George Coulouris, Jean Dollimore, Tim Kindberg, Sistemas Distribuídos Conceitos e Projeto, 5th Ed., Bookman, /30