Fundamentos Em Sistemas Operacionais

Fundamentos em

Sistemas Operacionais

Márcio Rodrigo Elias Carvalho

Jouberto Uchôa de MendonçaReitor

Amélia Maria Cerqueira UchôaVice-Reitora

Jouberto Uchôa de Mendonça JuniorPró-Reitoria Administrativa - PROAD

Ihanmarck Damasceno dos SantosPró-Reitoria Acadêmica - PROAC

Domingos Sávio Alcântara MachadoPró-Reitoria Adjunta de Graduação - PAGR

Temisson José dos SantosPró-Reitoria Adjunta de Pós-Graduaçãoe Pesquisa - PAPGP

Gilton Kennedy Sousa FragaPró-Reitoria Adjunta de Assuntos Comunitários e Extensão - PAACE

Jane Luci Ornelas FreireGerente do Núcleo de Educação a Distância - Nead

Andrea Karla Ferreira NunesCoordenadora Pedagógica de Projetos - Nead

Lucas Cerqueira do ValeCoordenador de Tecnologias Educacionais - Nead

Equipe de Elaboração e Produção de Conteúdos Midiáticos: Alexandre Meneses Chagas - Supervisor Ancéjo Santana Resende - CorretorAndira Maltas dos Santos – DiagramadoraClaudivan da Silva Santana - DiagramadorEdilberto Marcelino da Gama Neto – DiagramadorEdivan Santos Guimarães - DiagramadorFábio de Rezende Cardoso - WebdesignerGeová da Silva Borges Junior - IlustradorMárcia Maria da Silva Santos - CorretoraMarina Santana Menezes - WebdesignerMatheus Oliveira dos Santos - IlustradorMonique Lara Farias Alves - WebdesignerPedro Antonio Dantas P. Nou - WebdesignerRebecca Wanderley N. Agra Silva - DesignerRodrigo Otávio Sales Pereira Guedes - WebdesignerRodrigo Sangiovanni Lima - AssessorWalmir Oliveira Santos Júnior - Ilustrador

Redação:Núcleo de Educação a Distância - NeadAv. Murilo Dantas, 300 - FarolândiPrédio da Reitoria - Sala 40CEP: 49.032-490 - Aracaju / SETel.: (79) 3218-2186E-mail: [email protected]: www.ead.unit.br

Impressão:Gráfi ca GutembergTelefone: (79) 3218-2154E-mail: grafi [email protected]: www.unit.br

Banco de Imagens:Shutterstock Copyright © Sociedade de Educação Tiradentes

C331f Carvalho, Márcio Rodrigo Elias. Fundamentos em sistemas opera-

cionais. / Márcio Rodrigo Elias Carvalho. – Aracaju : UNIT, 2010.

176 p.: il. : 22 cm.

Inclui bibliografia.

1. Sistemas operacionais. 2. Informática. I. Universidade Tiradentes – Educação a Distância II. Titulo.

CDU : 004.451

Prezado(a) estudante, A modernidade anda cada vez mais atrelada ao

tempo, e a educação não pode ficar para trás. Prova disso são as nossas disciplinas on-line, que possibi-litam a você estudar com o maior conforto e comodi-dade possível, sem perder a qualidade do conteúdo.

Por meio do nosso programa de disciplinas

on-line você pode ter acesso ao conhecimento de forma rápida, prática e eficiente, como deve ser a sua forma de comunicação e interação com o mundo na modernidade. Fóruns on-line, chats, podcasts, livespace, vídeos, MSN, tudo é válido para o seu aprendizado.

Mesmo com tantas opções, a Universidade Tiradentes

optou por criar a coleção de livros Série Bibliográfica Unit como mais uma opção de acesso ao conhecimento. Escrita por nossos professores, a obra contém todo o conteúdo da disciplina que você está cursando na modalidade EAD e representa, sobretudo, a nossa preocupação em garantir o seu acesso ao conhecimento, onde quer que você esteja.

Desejo a você bom aprendizado e muito sucesso!

Professor Jouberto Uchôa de Mendonça

Reitor da Universidade Tiradentes

Apresentação

SumárioParte 1: Princípios e Estruturas de Sistemas

Operacionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Tema 1: Introdução aos Sistemas Operacionais . . . . . . . . . . . . . . . . . 13

1.1 História dos Sistemas Operacionais . . . . . . . . . . . . . . . . . . 14

1.2 Tipos de Sistemas Operacionais . . . . . . . . . . . . . . . . . . . . 23

1.3 Funções dos Sistemas Operacionais . . . . . . . . . . . . . . . . . .31

1.4 Estruturas do Sistema Operacional . . . . . . . . . . . . . . . . . . 39

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Tema 2: Gerenciamento de Processos . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.1 Conceitos Fundamentais de Processos . . . . . . . . . . . . . . . 52

2.2 Tipos de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

2.3 Comunicação entre Processos . . . . . . . . . . . . . . . . . . . . . . 69

2.4 Escalonamento de Processos . . . . . . . . . . . . . . . . . . . . . . . 79

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Parte 2: Funcionamento de Sistemas Operacionais . . . 87

Tema 3: Funções essenciais de um Sistema Operacional . . . . . . . . .89

3.1 Gerência de Múltiplos Processadores . . . . . . . . . . . . . . . . .91

3.2 Gerência de Memória . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.3 Memória Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

3.4 Gerência de Dispositivos de Entrada e Saída . . . . . . . . . 120

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Tema 4: Segurança de Sistemas Operacionais . . . . . . . . . . . . . . . . . 131

4.1 Sistemas de Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

4.2 Princípios de Segurança de Sistemas Operacionais . . . 144

4.3 Cases Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

4.4 Cases Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Ementa

Introdução aos Sistemas Operacionais: História dos Sistemas Operacionais, Tipos de Sistemas Opera-cionais, Funções de Sistemas Operacionais, Estruturas de Sistemas Operacionais. Gerenciamento de Proces-sos: Conceitos Fundamentais de Processos, Tipos de Processos, Comunicação entre Processos, Escalona-mento de Processos. Funções Essenciais de um Siste-ma Operacional: Gerência de Múltiplos Processadores, Gerência de Memória, Memória Virtual, Gerência de Dispositivos de Entrada e Saída. Segurança de Sistemas Operacionais: Sistemas de Arquivo, Princípios de Segurança de Sistemas Operacionais, Cases Windows, Cases Linux.

Objetivos

Geral

Levar ao aluno os conceitos básicos sobre os sistemas operacionais de forma a compreender o fun-cionamento lógico de um computador.

Específicos

• Compreender a importância das técnicas de sistemas operacionais nos computadores;

• Proporcionar aos alunos conhecimentos sobre a arquitetura funcional dos sistemas operacionais e suas relações com o proces-samento de dados;

Concepção da Disciplina

• Fornecer aos alunos as principais informa-ções para a identificação, entendimento e aplicação de sistemas de operacionais no processo operacional dos computadores e suas estruturas;

• Proporcionar entendimento das aplicabili-dades operacionais dos principais sistemas operacionais existentes.

Orientação para Estudo

A disciplina propõe orientá-lo em seus procedi-mentos de estudo e na produção de trabalhos científi-cos, possibilitando que você desenvolva em seus traba-lhos pesquisas, o rigor metodológico e o espírito crítico necessários ao estudo.

Tendo em vista que a experiência de estudar a distância é algo novo, é importante que você observe algumas orientações:

• Cuide do seu tempo de estudo! Defina um horário regular para acessar todo o conteúdo da sua disciplina disponível neste material impresso e no Ambiente Virtual de Aprendi-zagem (AVA). Organize-se de tal forma para que você possa dedicar tempo suficiente para leitura e reflexão;

• Esforce-se para alcançar os objetivos pro-postos na disciplina;

• Utilize-se dos recursos técnicos e humanos que estão ao seu dispor para buscar escla-recimentos e para aprofundar as suas reflexões. Estamos nos referindo ao contato permanente com o professor e com os cole-gas a partir dos fóruns, chats e encontros presenciais, além dos recursos disponíveis no Ambiente Virtual de Aprendizagem – AVA.

Para que sua trajetória no curso ocorra de forma tranquila, você deve realizar as atividades propostas e estar sempre em contato com o professor, além de acessar o AVA.

Para se estudar num curso a distância deve-se ter a clareza de que a área da Educação a Distância pauta-se na autonomia, responsabilidade, cooperação e colaboração por parte dos envolvidos, o que requer uma nova postura do aluno e uma nova forma de con-cepção de educação.

Por isso, você contará com o apoio das equipes pedagógica e técnica envolvidas na operacionalização do curso, além dos recursos tecnológicos que contribuirão na mediação entre você e o professor.

PRINCÍPIOS E ESTRUTURAS DE SISTEMAS OPERACIONAIS

Parte 1

1 Introdução aos Sistemas Operacionais

No texto a seguir, veremos os conceitos básicos e os principais fundamentos de sistemas operacionais. Juntos conheceremos sua evolução através da história, seus tipos e funções primordiais interagindo o usuário com o hardware do sistema.

Você será capaz, ao final deste tema, de perceber a complexidade envolvida na comunicação dos sistemas operacionais com os dispositivos físicos do computador a fim de criar um ambiente mais amigável para o usuário.

Fundamentos em Sistemas Operacionais14

1.1 História dos Sistemas Operacionais

Um sistema operacional pode ser visto como um conjunto de instruções executadas pelo proces-sador que gera determinado resultado. Analisando desta forma, sugiro levantar a seguinte questão: Podemos considerar o sistema operacional um pro-grama da mesma forma que um aplicativo de usuário?

Para responder com segurança esta questão é preciso saber mais sobre as funções de um sis-tema operacional e para isso nada melhor do que analisarmos a evolução do desenvolvimento dos computadores, já que os sistemas operacionais estão historicamente ligados a ela. Vejamos então um pequeno resumo dos principais fatos históricos.

Desde 1642, quando Blaise Pascal (1623-1662), matemático inglês, inventou uma máquina de somar, diversos matemáticos se esforçaram em criar máquinas para calcular operações aritméticas. Até que em 1833, Charles Babbage (1791-1871) projetou uma máquina capaz de realizar qualquer tipo de operação chamada “Máquina Analítica”.

Figura 01 – Parte de um desenho da máquina analítica de Babbage

Fonte: GUIMARÃES, Angelo M.; CASTILHO, Newton A. Introdução à ciência da computação. 2. ed. Rio de Janeiro: LTC, 1985, cap. 1, p. 12.

15Tema 1 | Introdução aos sistemas operacionais

Apesar da impossibilidade de sua construção, devido aos limites tecnológicos da época, seus con-ceitos de uma unidade central de processamento, de dispositivos de entrada e saída, memória e, é claro, o fato de ser programável, torna o seu inven-to o que mais se aproxima de um computador atual.

Outro personagem da história que vale a pena ser citado é George Boole (1815-1864), tam-bém matemático inglês, criador da lógica booleana em 1854, base da computação digital utilizada até hoje e que permitiu o desenvolvimento de compo-nentes como relés e válvulas, implementados nos primeiros computadores em 1940.

Nos anos de 1900 apontamos outro marco importante no desenvolvimento dos computadores. No final da década de 30, Alan Turing (1912-1954), um matemático inglês, publicou em um trabalho científico uma máquina imaginária, projetada para executar uma operação matemática específica. Em outras palavras, a máquina seria capaz de reali-zar uma série de etapas fixas, prescritas, que, por exemplo, resultariam na multiplicação de dois nú-meros. E imaginou um conjunto dessas máquinas, cujo funcionamento interno pudesse ser alterado, realizando todas as funções matemáticas concebí-veis. Chamou-a de Máquina Universal de Turing.

Alguns anos depois, durante a Segunda Guerra, o também matemático inglês Max Newman (1897-1984), baseou-se em grande parte no con-ceito de Alan Turing para uma máquina universal, projetando uma máquina capaz de se adaptar a diferentes problemas.

Como você conceituaria hoje um compu-tador programável? Se o que pensou foi uma máquina capaz de se adaptar a dife-rentes problemas, está correto.


Em 1943, através do projeto de Newman, foi construído pelo engenheiro inglês, Tommy Flowers (1905-1998), o Colossus, considerado o precursor do moderno computador digital.

Dois anos depois, em 1945, J. Eckert (1919-1995) e J. W. Mauchly (1907-1980), da Universidade da Pensilvânia, completaram o ENIAC (Electronic Numerical, Integrator And Calculator) que consistia em 18.000 válvulas eletrônicas capazes de realizar cinco mil cálculos por segundo.

O professor John Von Neumann (1903-1957), que trabalhou como consultor na construção do ENIAC, desenvolveu a ideia de uma máquina de propósito geral na qual tanto as instruções quanto os dados compartilhassem uma mesma memória. Este conceito, hoje conhecido como Ar-quitetura Von Neumann, é a base da arquitetura da computação atual.

Você consegue perceber que com a Arquitetura de von Neumann foi possível colocar as ideias de Babbage e Turing em um mesmo sistema computacional?

Diversos computadores foram construídos com o conceito da Arquitetura de von Neumann (também chamado de “programa armazenado”). Vale a pena citar o EDSAC (Electronic Delay Stora-ge Automatic Calculator), construído em Cambridge, Inglaterra, em 1949, por ter sido o primeiro com-putador a implementar esse conceito, e o EDVAC (Electronic Discrete Variable Automatic Computer) construído na mesma época, na Pensilvânia, EUA1.

Sugiro aqui uma pausa para levantar a seguinte questão: E os sistemas operacionais? Onde entram nesta história?

1 Reveja o conte-údo da disciplina Introdução à Com-putação e relembre com mais detalhes seus conhecimentos em relação ao desenvolvimento dos computadores até a importância da invenção do transistor.


Até a década de 50, os computadores ainda não possuíam interface com o usuário como tecla-dos e monitores e o conceito de sistema operacional surgiria somente nesta década.Até então, os programas eram perfurados em cartões que eram carregados em uma leitora para serem gra-vados em uma fita de entrada. Essa fita era, então, lida pelo computador que rodava um programa por vez, gravando o resultado de seu processamento em uma fita de saída lida pelo computador que rodava um programa por vez, gravando o resultado de seu processamento em uma fita de saída. Quando todos os programas terminavam sua execução, a fita de sa-ída era lida e impressa. Esse processamento, em que vários programas eram submetidos ao computador, era conhecido como processamento batch.

Figura 02 – Exemplo de cartão perfurado

Fonte: GUIMARÃES, Angelo M.; CASTILHO, Newton A. Introdução à

ciência da computação. 2. ed. Rio de Janeiro: LTC, 1985, cap. 5, p. 117.

O primeiro sistema operacional foi desen-volvido em 1953, pelo grupo de usuários de um computador IBM (IBM 701) para tentar automatizar as tarefas manuais de inserção de cartões para a leitura. Pela simplicidade deste sistema, ficou co-nhecido como monitor.


Com o desenvolvimento dos circuitos integra-dos na década de 60, houve um grande aumento do poder de processamento e, com isso, inúme-ras inovações na área de sistemas operacionais surgiram, com a implementação de técnicas pre-sentes até hoje, sendo a multiprogramação a mais importante de todas. Isto porque, sem o conceito de multiprogramação, toda vez que um programa realizava uma operação de acesso a dispositivos de entrada e saída, o processador tinha de aguardar o término deste processo. Contudo, com a multi-programação, programas poderiam compartilhar a memória e aguardar os dispositivos de entrada e saída enquanto o processador se ocupava de outro programa.

Em 1962 o MIT (Massachusett Institute Technology) desenvolveu um dos primeiros siste-mas operacionais de tempo compartilhado, o CTSS (Compatible Time Sharing System) que suportava no máximo 32 usuários.

Em 1964 a IBM lança o System /360, que re-volucionou a indústria de informática por diversos motivos: foi a primeira linha de computadores a utilizar circuitos integrados em pequena escala e introduziu o conceito de máquinas de diferentes portes com a mesma arquitetura onde era possível que programas escritos em uma máquina pudessem ser executados em outra.

Em 1965, a General Electric, a Bell Labs e o MIT estavam desenvolvendo um projeto de um sistema operacional portável, que poderia ser uti-lizado em plataformas de hardware diferentes. O MULTICS (Multiplexed Information and Computing Service) implementava memória virtual, multipro-gramação e deveria suportar múltiplos processadores e usuários.


Já em 1969, Ken Thompson começou a escrever uma versão simplificada monousuária do MULTICS (ele fez parte do projeto de sua criação) para um minicomputador na Bell Labs. Seu trabalho mais tarde deu origem ao sistema operacional UNIX, que devido ao fato de seu código fonte estar ampla-mente disponível, várias organizações criaram suas próprias versões, que não eram compatíveis entre si, o que levou ao desenvolvimento de um padrão para o UNIX chamado POSIX.

Na década de 70, com o advento da integração em larga escala (LSI – Large Scale Integration e VLSI – Very Large Scale Integration), fez com que a miniaturização e o barateamento dos computa-dores se tornassem possíveis. Nesta mesma década, mais precisamente em 1974, a Intel produz o micro-processador Intel 8080 utilizado no primeiro micro-computador, o Altair.

Em 1976, Steve Wozniak e Steve Jobs fabri-cam o Apple II com microprocessador de 8 bits e no mesmo ano são fundadas a Microsoft e a Apple.

Em 1981 a IBM lança sua filosofia de com-putador pessoal lançando o PC-XT (Personal Com-puter – Extended Technology) que vinha com um processador Intel 8088 de 16 bits e com o sistema operacional baseado em linha de comando, o MS-DOS (Microsoft – Disk System Operation).

Esse sistema operacional iria evoluir jun-tamente com os micros que ficaram conhecidos como 286, 386, 486 e a linha Pentium recebendo um shell que rodava por cima do MS-DOS que ficou conhecido como Windows, até que em 1995 foi lançada uma versão que não dependia mais do MS-DOS por trás para rodar, ele foi chamado de Windows 95.


Lembra-se por que não era possível rodar o Windows 95 em um 286? Quem possuiu um 286 na época e tentou instalar o Win-dows 95 obviamente não teve sucesso, já que o Windows 95 era um sistema opera-cional de 32 bits, enquanto um processa-dor 286 trabalhava a 16 bits.

Em meio a esses acontecimentos, em 1982, foi fundada a SUN Microsystems, que lançou as pri-meiras estações RISC com o sistema operacio-nal SunOS e logo depois o Sun Solaris. Surgiram, assim, os sistemas operacionais para redes e sistemas distribuídos.

Na década de 90 houve a consolidação dos sistemas operacionais baseados em interfaces gráficas. Além disso, a utilização de conceitos e implementações, que eram usados em computa-dores de grande porte, passaram a ser utilizados em sistemas para desktop, como no Windows NT e Unix (IBM-AIX, HP-UX e Sun Solaris).

Ainda nos anos 90, mais precisamente em 1991, o estudante finlandês Linus Torvalds inicia o desenvolvimento do sistema operacional Linux, que foi “construído” a partir da colaboração de diversos programadores que auxiliaram no desen-volvimento do seu núcleo.

Já na década de 2000 temos os processa-dores de 64 bits, que necessitam de um sistema operacional que trabalhe a 64 bits. Além disso, vemos a Microsoft unificando recursos de servidores e desktops em suas novas versões de sistemas operacionais e a popularização das distribuições Linux como uma alternativa real para os usuários desktops.


Atualmente é possível rodar o Linux di-retamente do CD ou mesmo de um pen drive sem instalá-lo na máquina! Experi-mente.

Com a popularização da internet o concei-to de sistemas distribuídos será bastante explora-do nos sistemas operacionais. Com a redução do custo da tecnologia, dos custos de comunicação e aumento na taxa de transmissão temos sistemas operacionais hoje em telefones celulares, palmtops e diversos dispositivos móveis.

Neste sentido, os sistemas operacionais evo-luíram com o objetivo de facilitar o trabalho de co-dificação, execução e manutenção dos programas, já que esses programas deixaram de ter relação di-reta com o hardware dos computadores eliminando a necessidade dos programadores desenvolverem suas próprias rotinas de leitura/gravação específica para cada dispositivo.

INDICAÇÃO DE LEITURA COMPLEMENTAR

Para saber mais sobre História dos Sistemas Opera-cionais, leia o item 1.4 (p. 6-14) do livro de:

MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007.

No primeiro capítulo de um dos livros referência no assunto de sistemas operacionais, Francis Ma-chado e Luiz Maia resumem a história da evolução dos computadores em paralelo com a evolução dos sistemas operacionais analisando suas inovações a cada década do século passado.


Para saber mais sobre História dos Sistemas Opera-cionais, leia o item 1.2 (p. 19-25) do livro de:

TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000.

Livro referência no estudo de sistemas operacionais distribui em seu primeiro capítulo a evolução dos sistemas operacionais dentro do contexto das gerações de computadores ao longo do século passado.

PARA REFLETIR

Se equipamentos como celulares, palmtops, handhelds já vêm com um sistema operacional embutido, por que o microcomputador não possui este mesmo princípio? Pense a respeito.


1.2 Tipos de Sistemas Operacionais

Como foi visto no tópico anterior, a evolução do sistema operacional está associada diretamente à arquitetura dos computadores sobre o qual estão implementados e das aplicações por ele suportadas. Isso fez com que muita coisa mudasse num esforço para o aperfeiçoamento de interações e proces-samentos. Podemos a partir daí classificá-los em diferentes tipos:

Figura 03 – Tipos de sistemas operacionais

SISTEMAS MONOPROGRAMÁVEIS

Também conhecidos como Sistemas Mono-tarefa, caracterizam-se por permitir que todos os recursos do sistema fiquem exclusivamente dedica-dos a uma única tarefa. Só um programa pode ro-dar por vez, qualquer outra aplicação deverá aguar-dar seu término para que possa iniciar. Com isso, haverá uma subutilização dos recursos de hardware (memória, processador e periféricos).

Figura 04 – Sistemas Monoprogramáveis

Fonte: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas opera-cionais. 4. ed. Rio de Janeiro: LTC, 2007, cap. 1, p. 16.


O sistema operacional MS-DOS é um bom exemplo deste tipo de sistema. Foi criado com o princípio de que uma pessoa estaria usando o computador e um único usuário estaria executando uma tarefa de cada vez. O MS-DOS foi desenvolvi-do para ser usado em um ambiente monousuário e de monoprocessamento.

Uma vantagem nesse tipo de sistema é sua implementação, já que não existe a preocupação de criar soluções para o compartilhamento dos re-cursos de hardware entre os programas.

Quantas desvantagens você é capaz de enu-merar para um sistema monoprogramável?

SISTEMAS MULTIPROGRAMÁVEIS

Também conhecidos como Sistemas Multita-refas sua principal característica é o compartilha-mento dos recursos de hardware entre usuários e aplicações. Neste modelo, o sistema operacional se preocupa em gerenciar o acesso concorrente aos seus recursos de hardware, como memória, proces-sador e periféricos de forma ordenada e protegida entre os diversos programas.

Figura 05 – Sistemas Multiprogramáveis

Fonte: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio

de Janeiro: LTC, 2007, cap. 1, p. 17.


Este tipo de sistema pode ser classificado de acordo com o número de usuários que o uti-lizam. Podemos ter então um Sistema Multitarefa Monousuário, quando existe somente um usuário interagindo com o sistema. Um exemplo disso era o Windows 98, em que para trocar de usuário era necessário fazer o log off do usuário atual para acessar um novo usuário.

O outro tipo de sistemas multiprogramáveis é o Sistema Multitarefa Multiusuário, em que diversos usuários podem se conectar ao sistema simultane-amente. É o que acontece hoje com os usuários desktops do sistema Windows XP (ou posterior) ou as distribuições Linux, em que é possível ter vários usuários logados no sistema simultaneamente.

Os Sistemas Multiprogramáveis podem ainda ser classificados pela forma na qual suas aplicações são gerenciadas:

Sistemas Batch

Tinha como uma de suas características não necessitar da interação do usuário com a aplicação, suas entradas e saídas de dados eram implementadas normalmente por arquivos em disco.

Como visto no tópico anterior, na década de 60, os programas em um sistema Batch (conhecidos como job - algo parecido com os arquivos de lote do DOS), eram colocados em execução a partir de cartões perfurados e armazenados em disco ou fita, onde aguardavam para serem processados.

A implementação do sistema Batch fazia com que ao invés de os programas serem submetidos pelo operador, um a um, um conjunto de programas era submetido de uma só vez, permitindo um melhor aproveitamento do processador.


Sistemas de Tempo Compartilhado (time Sharing)

Sua característica é permitir que diversos pro-gramas sejam executados a partir da divisão do tempo do processador em pequenos intervalos, chamados de fatia de tempo (time-slice). O sistema cria um ambiente de trabalho próprio para cada usuário, dando a impressão de que todos os recur-sos estão disponíveis somente para ele.

Caso o tempo atribuído a determinado pro-grama não seja suficiente para sua conclusão, ele é interrompido e colocado em espera aguardando por uma nova fatia de tempo.

Ao contrário dos Sistemas Batch, os Sistemas de Tempo Compartilhado geralmente permitem a interação do usuário com o sistema através de ter-minais, por exemplo, para interromper a execução de um programa. Por isso, os sistemas de Tempo Compartilhado ficaram também conhecidos como sistemas on-line.

Sistemas de Tempo Real

A principal diferença entre Sistemas de Tem-po Compartilhado e Sistemas de Tempo Real é que neste último um programa utiliza o processador o tempo que for necessário, ou até que apareça outro mais prioritário, não existindo a ideia de time-slice.

Um fator questionável nesse tipo de geren-ciamento é que a importância ou prioridade de execução de um programa é definida pela própria aplicação e não pelo sistema operacional.

SISTEMAS COM MÚLTIPLOS PROCESSADORES

A principal característica deste sistema é pos-suir duas ou mais CPUs (ou UCP, Unidade Central de Processamento, em português) trabalhando em con-junto na execução de vários programas ao mesmo


tempo, ou em um único programa subdividido em partes para serem executadas simultaneamente por mais de um processador.

Os mesmos princípios básicos e benefícios aplicados à multiprogramação podem ser atribuídos a sistemas com múltiplos processadores, além de vantagens específicas como: disponibilidade, escalabilidade e balanceamento de carga.

A vantagem da disponibilidade está associa-da à capacidade de manter o sistema em operação mesmo em caso de falhas. Imagine um computador com dois processadores em que um deles apre-senta uma falha e suas atividades são automatica-mente transferidas ao outro processador de forma transparente para os usuários e os programas. Em situações como essa o que irá ocorrer, porém, é a diminuição da capacidade de processamento.

Já a característica da escalabilidade é a capacidade de ampliar o poder computacional do sistema apenas adicionando novos processadores. Não seria ótimo se ao perceber uma diminuição na performance de processamento ao utilizar um novo programa bastasse adicionar mais um processador ao invés de trocar todo o micro?

O que chamamos de Balanceamento de carga é a capacidade de distribuir o processamento entre os diversos processadores a partir da carga de trabalho de cada um.

O grau de compartilhamento entre a memó-ria e os dispositivos de entrada/saída com os pro-cessadores criam características distintas na forma como eles se comunicam entre si que podem ser classificadas como:

Sistemas Fortemente Acoplados (tightly coupled)

Neste tipo de sistema, vários processadores compartilham uma mesma memória física (memó-ria compartilhada) e o gerenciamento dos dispo-sitivos de entrada e saída é feito por um único sistema operacional. É também conhecido como Multiprocessadores.


Figura 06 – Sistemas fortemente acoplados

Fonte: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap. 1, p. 21.

Este sistema pode ser dividido em SMP - Mul-tiprocessadores Simétricos (Symmetric Multiproces-sors) onde o tempo de acesso à memória principal pelos processadores é uniforme e NUMA - Acesso à Memória Não-Uniforme (Non-Uniform Memmory Access) onde o tempo de acesso à memória pelos processadores varia de acordo com sua localização física, já que existem diversos conjuntos reunindo processadores e memórias conectados através de interconexões.

Sistemas Fracamente Acoplados (loosely coupled)

Possui dois ou mais sistemas computacionais conectados por meio de linhas de comunicação, cada uma possuindo seu próprio sistema opera-cional e gerenciando seus próprios recursos (UCPs, dispositivos de entrada/saída e memória). Também conhecido como Multicomputadores.

Se antes as aplicações eram centralizadas em sistemas de grandes portes com um ou mais processadores, onde terminais eram conectados através de comunicação serial (ou telefônica) para interagir neste sistema, hoje, devido à evolução da


telecomunicação, das tecnologias de redes e dos computadores pessoais, temos o modelo de rede de computadores. Neste modelo, sistemas opera-cionais de rede permitem que sistemas indepen-dentes (host) compartilhem recursos e informa-ções, tratando-os como um conjunto único, como se fosse um sistema fortemente acoplado.

A partir da integração dos hosts que compõem uma rede, os sistemas fracamente acoplados podem ser divididos em sistemas distribuídos e sistemas operacionais de rede. A principal característica que os difere é a capacidade do sistema em criar uma ima-gem única dos serviços disponibilizados pela rede.

Nos sistemas distribuídos, é possível um pro-cesso ser dividido em partes e cada uma dessas partes serem executadas por um host diferente da rede. Isso não é perceptível para o usuário e para a aplicação que tem a impressão de existir um único sistema centralizado.

Figura 07 – Sistemas fracamente acoplados

Fonte: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap. 1. p. 21.

Um bom exemplo disso foi o filme Titanic que utilizou dezenas de máquinas para renderizar os efeitos criados para o filme em um sistema distribuído que é conhecido como cluster.


Nos sistemas operacionais de rede, um host compartilha seus recursos com os demais hosts da rede. Um bom exemplo disso é uma rede local em que diversos microcomputadores utilizam a mesma impressora para impressão de arquivos.

Não é difícil concluir que em sistemas for-temente acoplados a taxa de transferência entre a memória e os processadores envolvidos no pro-cesso é muito maior, já que existe apenas uma me-mória principal sendo compartilhada por todos os processadores, enquanto nos sistemas fracamente acoplados esta taxa de transferência está limitada à velocidade da linha de comunicação entre os hosts.


Para saber mais sobre Tipos de Sistemas Operacionais, leia o item 1.5 (p. 15-22) do livro de:


Francis Machado e Luiz Maia expõem em seu livro de forma clara e dividido em tópicos os tipos de siste-mas operacionais ressaltando suas características e aplicações no ambiente computacional.

Para saber mais sobre Tipos de Sistemas Operacionais, leia o item 1.2 (p. 19-25) do livro de:



Livro referência no estudo de sistemas operacionais distribui em seu primeiro capítulo os tipos de sistemas operacionais dentro do contexto das gerações de computadores ao longo do século passado.

PARA REFLETIR

Diante do que foi visto, existe um tipo de sistema operacional que melhor atenderia a todo tipo de aplicação? Reflita sobre isso.

1.3 Funções dos Sistemas Operacionais

Nem todo dispositivo microprocessado pos-sui um sistema operacional. O microprocessador que controla o microondas na sua cozinha, por exemplo, não precisa de um sistema operacional. Ele possui um conjunto de tarefas prédefinidas e uma expectativa de entrada de comandos muito restrita e simples (um teclado numérico e alguns botões com funções prédefinidos). Além disso, sua configuração de hardware a ser controlada nunca será alterada, pois sua função será sempre a mesma.

Para o computador, porém, é indispensável a existência de um sistema operacional que pos-sua a habilidade de servir a uma diversidade de propósitos, interagir com o usuário das mais di-versas formas e lidar com os mais diversos tipos de hardware.


Pensando no trabalho de um usuário, inde-pendente das atividades e programas utilizados ao manipular o computador, percebemos que ele está sempre percorrendo o mesmo ciclo de trabalho, que pode ser visto da seguinte maneira:

Figura 08 – Ciclo de trabalho do usuário

Os diferentes programas existentes permitem que o usuário peça coisas diferentes e tenha, con-sequentemente, resultados diferentes. É o que dá ao computador a característica de ser programável. Você pode programá-lo para realizar determinada atividade e gerar um resultado específico.

Agora vamos questionar o seguinte: quando o usuário pede ao micro para executar um programa, quem verifica a existência desse programa? Quem acessa o disco para copiá-lo para a memória? Quem avisa ao processador que ele pode ser executado? E se o processador já estiver rodando um programa? E se a memória estiver cheia?

Essas são apenas algumas questões envol-vendo o gerenciamento do sistema operacional com alguns dispositivos de hardware. Algo que um programa de usuário não faria.

Outra abordagem para a compreensão do sistema operacional é o ponto de vista do usuário, em que o sistema operacional pode ser visto como uma interface entre o usuário e a máquina, isolando-o de toda a complexidade do hardware, gradual-mente, através de camadas de software por sobre


o hardware básico do micro, para gerenciar todas as partes do sistema, oferecendo uma interface amigável para este usuário (Máquina Estendida ou Máquina Virtual), mais fácil de entender e programar.

Figura 09 – Computador sob a ótica do usuário

Podemos então arriscar um primeiro conceito destacando o sistema operacional, das categorias existentes de softwares e suas funcionalidades, como o programa de sistema mais fundamental atuando como um intermediário entre o usuário e o hardware controlando-o e gerenciando processos, arquivos, recursos e usuários.

Uma visão ampla da funcionalidade de um sistema operacional apresenta-o como um gerente. Ele é o responsável pelo gerenciamento de recursos, gerenciamento de dados, gerenciamento de tarefas e o gerenciamento do usuário.

Gerenciamento de Recursos

A função de gerenciamento de recursos de um sistema operacional envolve a alocação de dispositivos computacionais como: tempo de uso do processador, memória principal, memória virtu-al e dispositivos de entrada/saída.

Pensando no sistema operacional como um gerenciador de recursos, estamos levando em consideração todas as partes de um sistema com-plexo, no qual recursos de hardware (dispositivos


de entrada/saída - disco, impressora, vídeo, etc.) podem ser utilizados por diversos processos que competem pela utilização dos mesmos.

Na gerência do processador, o sistema opera-cional é responsável por alocá-lo entre os diferentes programas usando um algoritmo de agendamento específico. O tipo de agendamento é totalmente dependente do sistema operacional, de acordo com o objetivo desejado.

Ao gerenciar a memória, o sistema operacio-nal é responsável por alocar o espaço de memória para cada aplicação e para cada usuário. Se não houver espaço físico suficiente na memória, o sis-tema operacional pode criar em uma área do dis-co um espaço conhecido como memória virtual. A memória virtual permite que você rode aplicativos utilizando mais memórias do que a disponível no sistema.

A gerência dos dispositivos de entrada e saída envolve o controle de acesso a esses dispositivos pelos programas através de seus drivers de controle.

Gerenciamento de Dados

A função de gerenciamento de dados de um sistema operacional implica no controle da entrada e saída de dados, sua alocação, armazenamento e recuperação, lendo e escrevendo esses dados em um sistema de arquivo específico com permissões bem definidas de autorização e acesso.

Gerenciamento de Tarefas

A função de gerenciamento de tarefas de um sistema operacional é preparar, agenda, controlar e monitorar a execução de tarefas para garantir seu pro-cessamento da maneira mais eficiente. Essas tarefas


correspondem a um ou mais programas relaciona-dos e seus dados.

SERVIÇOS DE SISTEMAS OPERACIONAIS

Um sistema operacional fornece certos serviços aos programas e aos usuários desses programas, e apesar de alguns serviços específicos poderem diferir de um sistema operacional para outro, pode-mos identificar os mais comuns:

Um sistema operacional deve ser capaz de carregar um programa na memória, executá-lo e en-cerrar sua execução, seja de forma normal ou por indicação de erro;

Um programa em execução pode precisar da utilização de dispositivos de entradas e saídas, ta-refa que não pode ser controlada diretamente pelo usuário. O sistema operacional deve então fornecer os meios para realizar o controle de todas as operações de entrada e saída;

Existem situações em que um processo pode precisar trocar informações com outro processo. Nessas situações, a comunicação entre processos executados em diferentes sistemas de computação, ligados por uma rede, pode ser feita através de pa-cote de informações movido entre processos pelo sistema operacional;

Erros podem ocorrer no processador e na me-mória, nos dispositivos de entrada e saída e no pro-grama de usuário. Para cada tipo de erro, o sistema operacional deve tomar uma decisão adequada para garantir uma computação consistente e correta.

CHAMADAS DE SISTEMA

A interface entre o sistema operacional e seus programas aplicativos pode ser definida pelo conjunto das chamadas de sistema (system calls) que o sistema operacional proporciona.


Quando uma chamada de sistema é feita, o usuário solicita ao sistema operacional que realize uma operação em seu nome.

Chamada de sistema para o gerenciamento de processos

Do ponto de vista do sistema operacional, um processo constitui-se de certo tipo de atividade. Ele possui um programa, uma entrada, uma saída e um estado. Durante o tempo de vida de um processo, ele pode passar basicamente pelos estados: rodan-do (running), estado em que o processo está usan-do o processador neste instante; bloqueado (wait), significa que o processo está impedido de rodar até que ocorra um evento externo ao processo e; pron-to (ready), em que o processo está em condições de rodar, mas bloqueado temporariamente para dar vez a outro processo.

Figura 10 – Estados de um processo

A criação e a finalização de um processo geralmente ocorrem com uma chamada de sistema.

Chamadas de sistema para SinalizaçãoEm determinados casos pode ser necessário

interromper a execução de um processo, seja por instruções ilegais ou por motivos planejados. Por exemplo, imagine que você peça para o sistema


fazer uma verificação completa em busca de erros no disco e decide interrompê-la durante sua execução. É preciso haver alguma forma de interromper o programa e eliminar o processo sem prejuízos ao sistema. É o que faz a chamada de sistema para a sinalização.

O sistema de sinalização também é utilizado para o controle de limite de tempo de execução, além do tratamento de falhas. Imagine um proces-so que dependa de uma sinalização para dar pros-seguimento à sua tarefa. Um bom exemplo seria você pedir para listar o conteúdo de um diretório e pressionar a tecla pause para interromper a rola-gem de tela. Neste caso, a chamada de sistema a ser aplicada seria o pause que permitiria interromper o processo até que uma sinalização indicasse sua continuidade.

Chamadas de sistema para o gerenciamento de Arquivos

Muitas chamadas de sistema estão associa-das com o sistema de arquivos e seus métodos de acesso. Uma solicitação para a criação de um arquivo utiliza uma chamada de sistema, para ler um arquivo, outra chamada, e assim por diante. Normalmente as chamadas de sistema para o ge-renciamento de arquivos são: criar (create), abrir (open), gravar (write).

Chamadas de sistema para o gerenciamento de diretórios e sistemas de arquivo

Essas chamadas de sistema atuam com diretó-rios ou com o sistema de arquivo, ao invés de se rela-cionarem com um arquivo específico. As chamadas de sistema envolvidas nesse tipo de gerenciamento são


a criação (mkdir) e exclusão (rmdir) de diretórios e a montagem (mount) e a desmontagem (umount) de um dispositivo para o acesso aos seus arquivos e diretórios.

Chamadas de sistema para o gerenciamento de tempo

As chamadas de sistema para o gerenciamento de tempo dizem respeito ao relógio e são respon-sáveis por retornar a hora do sistema, permitir que o relógio seja configurado, retornar as informações de tempo de utilização do processador, entre outros.


Para saber mais sobre Funções dos sistemas Ope-racionais leia o Capítulo 3 (p. 33-40) do livro de:

SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas operacionais com java - conceitos e apli-cações.Tradução da 6. ed. Rio de Janeiro: Campus, 2005.

Na introdução de seu livro, Silberschatz, Gagne e Galvin apresentam resumidamente, mas de forma bastante clara, o conceito de sistemas operacionais e suas principais funções

Para saber mais sobre Funções dos sistemas Operacionais leia o item 1.3 (p. 25-39) do livro de:



Tanenbaum e Woodhull não só apresentam o assunto das chamadas de sistemas mais comuns do sistema operacional como analisam algumas linhas de código de sua execução.

PARA REFLETIR

Após ler sobre as funções de um sistema operacional, podemos pensar por que algumas tarefas são realizadas por ele e não diretamente pelo hardware ou pelo usuário. Reflita sobre isso.

1.4 Estruturas do Sistema Operacional

O sistema operacional é composto por um conjunto de rotinas conhecido como núcleo do sis-tema (kernel). Além disso, a maioria dos sistemas operacionais possui ferramentas de apoio ao usu-ário que são utilitários e linguagem de comandos, mas que não fazem parte do núcleo do sistema.

Linguagem de comandoDas formas existentes de o usuário se comu-

nicar com o kernel do sistema operacional, a mais amigável é através dos utilitários e linguagem de comandos supracitados. Normalmente cada siste-ma operacional possui seus utilitários específicos e comandos com estrutura e sintaxe próprias.


Figura 11 – Exemplos de comandos do Linux

Como podemos observar na figura acima, através da linguagem de comando o usuário pode executar diversas tarefas específicas do sistema como criar diretórios, ler ou excluir arquivos. Assim, o usuário possui uma forma direta de diálogo com o sistema operacional.

Depois de digitado pelo usuário, cada co-mando é interpretado pelo interpretador de coman-dos (shell), que verifica a sintaxe, executa chama-das às rotinas do sistema e apresenta o resultado. Normalmente, o interpretador de comando não faz parte do kernel, o que possibilita a existência de diferentes linguagens de comando para o mesmo sistema. No Linux, por exemplo, existem diversos interpretadores, o Bash, SH, CSH e outros.

Em muitos sistemas operacionais, as lingua-gens de comando se tornaram mais amigáveis em sua interação com o usuário, adotando interfaces gráficas com a utilização de ícones e janelas, a exemplo do Mac OS e MS Windows. Em muitos casos, essa interface gráfica é somente mais um nível de abstração entre o usuário e os serviços do sistema operacional.


Figura 12 – Interface do usuário com o sistema operacional

Fonte: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap. 4, p. 56.

Estruturas do Núcleo

O projeto de um sistema operacional é muito complexo e precisa atender a diversos requisitos, além de depender da estrutura do hardware a ser utilizado e do tipo de sistema que se pretende criar.

Quando os primeiros sistemas operacionais foram criados, seus códigos possuíam aproxi-madamente um milhão de linhas de código (IBM OS/360) e foi escrito completamente em assembly. Com a evolução dos sistemas, houve o aumento do número de linhas de códigos para algo perto de 20 milhões (MULTICS). Com o tempo, técnicas de programação modular e linguagens de alto nível foram incorporadas ao projeto.


Atualmente, tem-se sistemas operacionais com mais de 100 milhões de instruções (MS-Win-dows Vista), sendo que grande parte é escrita em C/C++, o que acarreta uma perda de desempenho. Por isso, as partes mais críticas do sistema conti-nuam sendo desenvolvidas em assembly (como o algoritmo de escalonamento do processador e o tratamento de interrupções, por exemplo), já que é uma linguagem de mais baixo nível, portanto mais próxima do hardware.

É importante ressaltar aqui que as linguagens de alto nível permitem que o sistema operacional seja facilmente alterado para outra arquitetura de hardware, além de facilitar o desenvolvimento e a manutenção do sistema.

A estrutura do núcleo pode variar conforme a concepção do projeto. As quatro principais estrutu-ras dos sistemas operacionais são:

• Sistemas Monolíticos;

• Sistemas em Camadas;

• VM - Máquina Virtual (Virtual Machine);

• Sistemas Cliente-Servidor – MicroKernel.

Vejamos alguns detalhes de cada uma delas

Sistemas Monolíticos

Sua arquitetura é como um grande e único programa executável formado por módulos (que contém todos os procedimentos) compilados indi-vidualmente e agrupados em um único objeto.

Quem já utilizou o MS-DOS (sistema operacio-nal da Microsoft, antecessor do Windows) conheceu um sistema operacional de núcleo monolítico.


Veja na figura abaixo um exemplo de estrutura de núcleo monolítico:

Figura 13 - Modelo de estruturação de sistema monolítico

Fonte: O autor, baseado na ilustração do livro: TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000, cap. 1, p. 41.

Apesar de o sistema operacional neste modelo ser escrito com uma coleção de procedimentos, na qual cada um pode chamar qualquer um dos outros sempre que precisar, o que sugere uma ausência de organização, é possível obter um mínimo de estrutura.

Nesta organização do núcleo, um programa principal chama o procedimento de serviço e este procedimento de serviço (ou um conjunto deles) executa cada uma das chamadas do sistema. Ressaltamos que um conjunto de procedimentos utilitários auxilia na execução dos procedimentos de serviços.

Sistemas em Camadas

Com o aumento da complexidade e conse-quentemente do tamanho do código dos sistemas operacionais, a organização dos projetos passou a ser estruturada e modular. Neste tipo de arquitetura, o sistema é dividido em níveis sobrepostos, em que cada camada oferece um conjunto de instruções a serem utilizadas pela camada superior a ela.


O fato de seu núcleo ser construído em uma hierarquia de níveis torna seu kernel mais indepen-dente em relação aos outros módulos, pois se uma aplicação travar, não irá afetar seu núcleo.

A maioria das versões do Unix e do MS-Windows está baseada no modelo de duas camadas, onde existem os modos de acesso usuário (sem privilégio) e kernel (privilégio de núcleo do sistema).

Figura 14 - Modelo de estruturação em camadas

Fonte: O autor, baseado na ilustração do livro: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap. 1, p. 59.

Um fato curioso, apesar de o computador “THE” (do holandês - Technische Hogeschool Ein-dhoven) ter sido o primeiro sistema a utilizar esta abordagem, podemos considerá-lo um sistema mo-nolítico disfarçado, pois todas as partes precisavam estar ligadas entre si gerando um único programa objeto.

Posteriormente, o MULTICS (visto no conte-údo 1.1) foi desenvolvido com uma série de anéis concêntricos, com os internos sendo mais privile-


giados que os externos. VM - Máquina Virtual (Virtual Machine)

Este modelo cria um nível intermediário entre o hardware e o sistema operacional, criando cópias virtuais do hardware (máquinas virtuais). Como cada máquina virtual é independente da outra, é possível coexistir sistemas operacionais diferentes no mesmo computador.

Esta estrutura oferece uma grande segurança entre cada máquina virtual já que existe um isola-mento total entre elas. Uma desvantagem é a gran-de complexidade do gerenciamento dos recursos da máquina entre as VMs.

Figura 15 - Máquina virtual

Fonte: O autor, baseado na ilustração do livro: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap1, p. 60.

Essa ideia de uma máquina virtual foi mui-to utilizada em um contexto um pouco diferente. Para que fosse possível rodar programas no antigo MS-DOS em processadores Pentium, a Intel disponibili-zou um modo virtual 8086 em seu processador, incluindo um endereçamento de 16 bits com um limite de 1Mb.


Sistemas Cliente-Servidor – MicroKernel

Uma tendência nos sistemas operacionais modernos é mover o código para camadas mais altas e remover tanto quanto possível do sistema operacional deixando um mínimo de kernel. Neste modelo, para requisitar um serviço, um processo de usuário (chamado de processo cliente) envia a requisição para um processo servidor que então faz o trabalho e remete de volta a resposta. Tudo que o kernel faz é gerenciar a comunicação entre clientes e servidores.

É um tipo de sistema em que as funções do sistema operacional ficam isoladas através de di-versos processos servidores pequenos, possuindo uma grande adaptabilidade para uso em sistemas distribuídos.

Figura 16 - O modelo cliente-servidor

Fonte: O autor, baseado na ilustração do livro: TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacionais: projeto e implementação. 2, ed. Porto Alegre: Bookman, 2000, cap. 1, p. 44.

Este modelo permite que os servidores não tenham acesso direto a alguns componentes do sistema, pois trabalham em modo usuário, apenas o núcleo do sistema, responsável pela conversa en-tre clientes e servidores, executa no modo kernel.

Isso aumenta a disponibilidade do sistema, já que se o servidor parar, o sistema não ficará inteiramente comprometido.

Uma outra característica do modelo cliente-servidor é que os servidores se comunicam através


da troca de mensagens, logo, não faz diferença se os clientes e servidores são executados em um sis-tema com um único processador ou com múltiplos processadores.

A implementação do modelo cliente-servidor em sistemas distribuídos permite que ao ser solici-tado um serviço, a resposta seja processada remo-tamente. Isso permite acrescentar novos servidores à medida que o número de clientes aumenta (escalabilidade).


Para saber mais sobre Estruturas de sistemas operacionais leia o Capítulo 4 (p. 50-62) do livro de:


A apresentação em tópicos da arquitetura dos siste-mas operacionais torna sua abordagem clara e ilus-trativa, com destaques relevantes das características de vantagens e desvantagens de cada modelo.

Para saber mais sobre Estruturas de sistemas operacionais leia o item 1.5 (p. 39-43) do livro de:


A análise dos computadores que utilizavam cada uma das arquiteturas dos sistemas operacionais apresentados, com seus detalhes de capacidade


e componentes de hardware, nos dá uma ideia da evolução dos diferentes desenvolvimentos de projetos de sistemas operacionais.

PARA REFLETIR

Uma vez visto as principais estruturas do núcleo de um sistema operacional, você conseguiria indicar um deles como sendo o mais eficaz para os mi-cros de hoje? Discuta com seus colegas e procure justificar sua escolha. Além disso, publique suas conclusões no AVA.

RESUMO

No conteúdo 1.1 vimos juntos a evolução dos sis-temas operacionais por meio de um pequeno re-sumo dos principais fatos históricos que marca-ram o desenvolvimento dos computadores.

Na sequência, no conteúdo 1.2, conhecemos as classificações dos tipos de sistemas operacionais, suas principais características e aplicações.

Seguindo com nossos estudos, no conteúdo 1.3, aprendemos sobre os diferentes objetos geren-ciados pelo sistema operacional e as principais chamadas de sistema responsáveis pela interface entre o usuário e o sistema operacional, o que


contribuirá para uma melhor compreensão do próximo tema que tratará sobre os processos

Por fim, no conteúdo 1.4 vimos as suas principais estruturas de composição do núcleo, as vantagens e desvantagens de cada uma dessas estruturas.

Gerenciamento de Processos2Neste texto trabalharemos sobre uma das funções mais essenciais

do sistema operacional que é o gerenciamento dos processos, já que tudo mais gira em torno de seu conceito.

Ao final deste tema você será capaz de compreender melhor como os processos conversam entre si, seus tipos, estados e os critérios existentes para seu escalonamento.


2.1 Conceitos Fundamentais de Processos

Antes de entrarmos a fundo no assunto de processos, é importante distinguirmos bem dois conceitos fáceis de confundir: o de programa e o de processo. Você saberia diferenciá-los?

Conforme visto no tema passado, no item chamada de sistema para o gerenciamento de processo, o processo constitui-se de certo tipo de atividade, e possui uma entrada, uma saída e um estado, enquanto um programa é um conjunto de códigos com uma finalidade específica.

Não é errado entendermos um processo como um programa em execução, mas seu significado vai além disso. Podemos ter diversos programas concorrendo na utilização do processador onde seus processos são alternados de acordo com o controle do sistema operacional.

Assim, podemos dizer também que um processo é uma espécie de ambiente onde um programa é executado. Um programa sempre está associado a um processo.

Vamos deixar de lado todos os nomes téc-nicos usados e fazer uma analogia para esclarecer melhor os conceitos e funções de cada um.

Imagine um maestro diante de sua partitura para reger uma orquestra de 30 músicos. Para quem não tem intimidade com uma partitura, basta saber que uma partitura possui todas as instruções necessá-rias (nome da nota, valor, duração, interpretação, pausas, etc.) para que o músico a execute em seu instrumento.

Na analogia acima, o maestro é o processador (CPU), a partitura é o programa (um algoritmo escrito em uma linguagem conveniente), os músicos da orquestra são os dados de entrada. O processo é a atividade do maestro de ler a partitura e reger os músicos que irão tocar a música.

53Tema 2 | Gerenciamento de processos

Ilusão de paralelismo

Desnecessário dizer que qualquer computador desktop hoje consegue fazer várias coisas ao mesmo tempo. Enquanto executa um programa de usuário, pode também estar enviando um texto para a impressora, uma música para a saída de áudio e lendo um arquivo em disco. Bem, na verdade, não é correto dizer ao mesmo tempo. Você concorda com isso?

Em um instante de tempo qualquer um pro-cessador executa somente um programa. No inter-valo de 1 segundo, o processador pode ter exe-cutado diversos programas, dando a ilusão de paralelismo. Essa rápida alternância é chamada de multiprogramação, como foi visto no tema anterior.

O paralelismo verdadeiro ocorre quando te-mos um sistema com multiprocessadores (com dois ou mais processadores compartilhando a mesma memória física).

Extrapolando nossa analogia anterior, é como se tivéssemos um maestro para reger duas orquestras cada uma tocando uma música distinta. Ou rege uma por vez, ou precisaríamos de mais de um maestro para que ambas fossem regidas simulta-neamente.

Processos e os tipos de sistemas operacionais

No item passado conhecemos os tipos de sistemas operacionais existentes, e em todos eles a gerência de processos é uma das principais funções do sistema operacional, possibilitando aos programas alocar recursos, compartilhar dados sincronizar suas execuções e trocar informações.

Nos sistemas multiprogramáveis, os processos concorrem entre si compartilhando o processador, memória e dispositivos de entrada/saída


Nos sistemas com múltiplos processadores existe não só a concorrência de processos pelo uso do processador, como a possibilidade de execução simultânea de processos nos diferentes processadores.

Já em um sistema multiusuário, cada usuá-rio tem um programa associado a seu processo e possui a impressão de possuir todos os recursos do computador exclusivos para seu uso, o que não acontece, já que todos os recursos estão sendo compartilhados.

Estrutura de um processo

Um processo é formado por três partes, conhecidas como contexto de hardware, contexto de software e espaço de endereçamento (MACHADO; MAIA, 2007). Estas partes juntas contêm todas as informações necessárias à execução de um programa.

Figura 17 - Estrutura do Processo

Fonte - MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap. 5, p. 67.


O contexto de hardware armazena o conteúdo dos registradores que é fundamental para sua im-plementação nos sistemas multiprogramáveis, onde os processos se alternam na utilização da CPU.

Quando o processo está em execução, seu contexto de hardware está armazenado nos regis-tradores do processador e no momento em que deixa de utilizar a CPU, o sistema operacional salva as informações no contexto do hardware do processo.

O contexto de software possui a maior parte das suas informações localizadas em um arquivo do sistema operacional conhecido como arquivo de usuários. Ali estão especificados os limites dos recursos que cada processo pode alocar. Muitas dessas características são geradas dinamicamente ao longo da execução do processo.

Além disso, cada processo possui seu próprio espaço de endereçamento, uma área da memória onde instruções e dados do programa são armazenados para execução.

Implementação de um processo

A implementação de um processo é feita pelo sistema operacional através de uma estrutura de dados chamada bloco de controle do processo (Pro-cess Control Block – PCB) e a partir desta estrutura, o sistema operacional mantém todas as informações necessárias sobre o processo.


Figura 18 - Bloco de Controle do Processo

Fonte - MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, cap.5, p. 71.

Além disso, o sistema operacional mantém uma tabela chamada tabela de processos, com uma entrada por processo. Nessa tabela de processos, o sistema operacional mantém ponteiros para cada bloco de controle de processos no contexto total do sistema ou por usuários.

Figura 19 - Tabela de Processos

Fonte - DEITEL, Paul; DEITEL, Harvey; CHOFFNES David. Sistemas operacionais. 3. ed. Prentice Hall Brasil, 2005, cap. 2, p. 57.


Todas as informações do processo devem ser salvas quando o processo alterna do estado rodando para o estado pronto, para que ele possa ser reini-ciado mais tarde do ponto onde parou (veja sobre estados de um processo no tópico abaixo).

Toda a gerência dos processos é realizada através de chamadas de sistema que realizam operações como criação, visualização, eliminação, dentre outras.

Estados de um processo

Como mencionado no tema anterior, um pro-cesso pode ter até três estados, gerando quatro tipos de transições na mudança de um estado para outro. No estado rodando (running), o pro-cesso está efetivamente utilizando o processador e pode ser colocado nos estados bloqueado (wait) ou pronto (ready).

Figura 20 - Estados de um processo

Fonte - TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas opera-cionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000,

cap.2, p. 58.

Sua transição para bloqueado2 pode ocorrer quando um processo logicamente não pode conti-nuar, normalmente porque está aguardando uma entrada que não está disponível ainda.

2 Alguns preferem chamar de estado de espera.


Sua transição para pronto ocorre quando o sistema operacional decide dedicar a utilização da CPU a outro processo temporariamente, colocando o atual processo em estado de espera.

A transição do estado pronto para rodando ocorre quando todos os outros processos do estado pronto tiveram sua justa parte de utilização da CPU e é hora do primeiro deles utilizar a CPU para executar novamente.

Finalmente a transição do estado bloqueado para o estado pronto acontece quando a entrada que o processo estava aguardando passou a estar disponível. O processo passa então do estado blo-queado para o estado pronto aguardando a CPU estar disponível.

Vale destacar aqui que em algumas bibliogra-fias, a exemplo de Silberschatz, Gagne e Galvin, (p. 64, 2005), consideram a criação e o encerramento de um processo pelo sistema operacional como es-tados de um processo. O que acha?

Criação e encerramento de processos

No gerenciamento de processos, o sistema operacional é responsável pela criação e exclusão de processos de usuário e de sistema, o escalona-mento de processos e o fornecimento de mecanis-mos para a sincronização, comunicação e tratamen-to de deadlocks para processos.

O Deadlock é uma situação em que dois ou mais processos ficam bloqueados, pois um proces-so está aguardando a liberação de um recurso por outro processo que também aguarda a liberação de um recurso alocado pelo primeiro processo.

A criação de um processo ocorre quando o sistema operacional adiciona um novo bloco de controle de processo à sua estrutura e aloca um espaço de endereçamento na memória para uso.


Quando um processo é encerrado, a tabela de processos retira o processo de sua tabela e disponibiliza todos os seus recursos. Um processo pode ser encerrado por razões como a eliminação por outro processo, forçado por ausência de recursos disponíveis ou pelo término normal de sua execução.

A Hierarquia de Processos

Na maioria dos sistemas operacionais é preciso que exista alguma forma de criar e destruir pro-cessos conforme necessário durante a operação. Já utilizou o atalho CTRL+ALT+DEL para fechar um programa?

Normalmente quando um processo é criado, a chamada de sistema que o criou, gera uma cópia do processo que fez a chamada. O processo-filho resultante também pode chamar a mesma chamada de sistema, sendo possível assim obter uma inteira árvore de processos.

Figura 21 - Estrutura de processos e subprocessos



Qualquer que seja a natureza exata da chamada de sistema, um processo precisa dispor de uma maneira de criar outros processos. Cada processo tem um pai e pode ter zero, um, dois ou mais filhos.


Para saber mais sobre Conceitos Fundamentais de Processos, leia o Capítulo 5 (p. 65-83) do livro de:


Com um texto bem completo sobre a criação, estrutura, tipos e estados de processos, os autores Francis e Luiz Paulo conseguem criar um excelente conceito de processo antes de tratar de seu geren-ciamento pelo sistema operacional.

Para saber mais sobre Conceitos Fundamentais de Processos, leia o Capítulo 4 (p. 62-65) do livro de:

DEITEL, Paul; DEITEL, Harvey; CHOFFNES, David. Sistemas operacionais. 3. ed. São Paulo: Prentice Hall Brasil, 2005.

Em seu livro sobre sistemas operacionais, os con-sagrados autores Paul e Harvey apresentam uma excelente explicação sobre o conceito, estrutura e estados de processos.


PARA REFLETIR

Se dois processos podem necessitar utilizar ao mesmo tempo um dispositivo de entrada e saída, acredita que é possível uma solução definitiva para evitar que um processo impeça que o outro conclua sua execução? Pense a respeito.

2.2 Tipos de Processos

Um processo pode ser classificado de duas formas, de acordo com a utilização do processa-dor e dispositivos de entrada/saída. Assim, um pro-cesso pode ser conhecido como CPU-bound (ligado à CPU) quando passa grande parte do tempo utilizando o processador (running), ou no estado pronto (ready). É um tipo de processo que utiliza poucas operações de leitura e gravação. Um bom exemplo é em aplicações que realizam muitos cálculos.

Ou um processo pode ainda ser definido como I/O-bound (ligado à dispositivos de entrada/saída) quando passa grande parte do tempo no estado bloqueado (wait), pois efetua um grande número de operações de entrada/saída. Bons exemplos são aplicativos comerciais e que possuem interativida-de com o usuário.

Além disso, é importante sabermos que um processo pode possuir ao menos dois canais de co-municação pelos quais são realizadas as entradas e saídas de dados. Desta forma um processo é fo-reground quando permite a comunicação direta do processo com o usuário durante seu processamento. O processamento interativo, por exemplo, tem como base processos foreground.


Por outro lado, um processo background é aquele onde não existe a comunicação com o usu-ário durante seu processamento. O processamento tipo batch (vimos seu conceito no tema anterior) é realizado através de processos background. Lembra-se do arquivo Autoexec.bat em seu micro?

Threads

Tudo o que foi apresentado no item anterior sobre processos considerava um programa reali-zando um fluxo único de execução, com uma única linha de controle com um único contador de pro-grama em cada processo.

Contudo, muitos sistemas operacionais ofere-cem suporte a múltiplas linhas de controle dentro de um processo. Essas linhas de controle são cha-madas de threads.

O princípio de um ambiente multithread é onde um único processo pode suportar múltiplos threads, cada um associado a um pedaço do códi-go da aplicação. Isso permite economizar recursos do sistema e reduzir o tempo gasto na eliminação e troca de contexto de processos nas aplicações con-correntes, assim, não é necessário haver diversos processos para a implementação da concorrência.

Figura 22 - (a) Três processos, cada um com um thread.(b) Um processo com 3 threads.

Fonte - TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacionais: projeto e imple-mentação. 2. ed. Porto Alegre: Bookman, 2000, cap. 2, p. 52.


Um exemplo para entender a vantagem dos múltiplos threads está nos browsers (navegadores web). Ao acessar uma página web que contém várias imagens, o navegador deveria configurar uma conexão separada com o endereço da pági-na e requisitar cada imagem. Muito tempo seria desperdiçado estabelecendo e liberando todas es-sas conexões. Por existirem múltiplos threads no browser, muitas imagens podem ser solicitadas ao mesmo tempo, tornando o desempenho bem mais eficiente (TANEMBAUN; WOODHULL, 2000).

É importante sabermos ainda que Threads compartilham a CPU da mesma maneira que um processo, se um thread está aguardando um recurso, outro thread pode ser executado.

Cada thread possui seu próprio contexto de hardware, mas compartilha o mesmo espaço de endereçamento e contexto de software com os demais threads do processo. O compartilhamento do mesmo espaço de endereçamento permite que a comunicação entre eles dentro de um mesmo processo aconteça de forma rápida e simples.

Figura 23 - Processo Multithread



Um thread também pode ser visto como uma sub-rotina de uma aplicação que pode ser execu-tada paralelamente ao programa chamador. Assim, um ambiente multithread possibilita a execução concorrente de sub-rotinas dentro de um mesmo processo.

Implementação de Threads

A implementação dos threads acontece inter-namente através de uma estrutura de dados cha-mada de bloco de controle do thread (Thread Con-trol Block – TCB). Nesta estrutura está o contexto de hardware e algumas informações relacionadas ao thread como: estado de execução, prioridade, e outros. Não confunda PCB com TCB!

Em um ambiente de um thread (monothread), o processo é ao mesmo tempo a unidade de alo-cação de recursos e a unidade de escalonamento (veremos sobre escalonamento no item 2.4)

Em um ambiente multithreads, a unidade de alocação de recursos é o processo, onde o espaço de endereçamento é compartilhado por todos os threads do processo. Por outro lado, existe uma unidade de escalonamento independente para cada thread. Assim, o sistema não seleciona um processo para execução e sim um de seus threads.

Podemos concluir que a grande diferença entre as aplicações monothread e multithreads está no uso do espaço de endereçamento, onde esta úl-tima compartilha o espaço dentro de um mesmo processo.

Esta característica das aplicações multithreads permite que a troca de dados entre threads de um mesmo processo seja mais simples e rápida se compararmos com uma aplicação monothread.


Alguns benefícios dos threads

Em alguns programas, a utilização de threads pode melhorar o desempenho da aplicação apenas executando tarefas em background enquanto as operações de entrada/saída estão sendo processa-das. Aplicativos como editores de texto, planilha e imagens são bastante beneficiados quando desen-volvidos com base em threads.

E não só as aplicações podem se beneficiar dos múltiplos threads, o núcleo do sistema opera-cional pode também ser implementado com este conceito de forma benéfica, como na arquitetura microkernel (visto no tema passado, item 1.4).

Nos ambientes cliente-servidor threads são fundamentais para a solicitação de serviços remo-tos. Em um ambiente multithread, um thread pode solicitar um serviço remoto, enquanto o programa pode realizar outras atividades. Múltiplos threads permitem que diversos pedidos sejam atendidos simultaneamente.

Além disso, as aplicações concorrentes uti-lizando o conceito multithread possuem melhores desempenhos do que aplicações concorrentes im-plementadas com múltiplos processos, pois as ta-refas de criação, troca de contexto e eliminação de threads geram menor overhead (ficar suspenso).

Quando temos threads em um mesmo pro-cesso, além de possuir uma comunicação mais rá-pida e eficiente, eles podem compartilhar facilmen-te outros recursos, como temporizadores, sinais, atributos de segurança, etc.

Processos Cooperativos Os processos concorrentes em execução no

sistema operacional podem ser processos indepen-dentes ou cooperativos. Se um processo não pu-


der afetar ou ser afetado por outros processos executados no sistema, dizemos que é um processo independente. Qualquer processo que não compar-tilhe dados com outro processo é independente.

Já um processo é cooperativo se puder ser afetado ou afetar outro processo em execução no sistema. Qualquer processo que compartilhe dados com outros processos é um processo cooperativo.

Como fator que favorece um ambiente que permita a cooperação entre processos podemos citar o compartilhamento de informações, onde vá-rios usuários podem estar interessados na mesma informação.

A velocidade de processamento também é um fator para um ambiente de cooperação entre os pro-cessos, já que para que uma tarefa seja executada de forma mais eficiente, é necessário quebrá-la em sub-tarefas, cada uma sendo executada em paralelo às demais.

Outro fator que favorece um ambiente que per-mita a cooperação entre processos é construir um sis-tema de forma modular, dividindo suas funções em processos ou threads separados (modularidade).

A conveniência para se implementar processos cooperativos também é um fator que favorece um ambiente de cooperação entre processos, pois mes-mo um usuário único de um sistema pode executar muitas tarefas em determinado momento, como editar um texto, imprimir e compilar em paralelo. Para fixar, enumere os fatores que favorecem a cooperação entre processos.

Formas de Criação de Processos

Vimos anteriormente que a criação de um pro-cesso é responsabilidade do sistema operacional, ve-remos agora três principais formas de sua criação.


• Login Interativo - Por intermédio de um terminal, um usuário fornece ao sistema seu nome de identificação e uma senha, que são autenticados pelo sistema opera-cional e é criado um processo foreground onde é possível ao usuário interagir com o sistema através de uma linguagem de comando.

• Linguagem de Comandos - A partir de seu próprio processo, um usuário pode criar novos processos através de co-mandos da linguagem de comandos. O processo criado pode ser background ou foreground, dependendo do comando de criação utilizado.

• Rotina do Sistema Operacional – Qual-quer programa executável com o uso de rotinas do sistema operacional pode criar um processo. A rotina de criação de pro-cessos depende do sistema operacional e possui diversos parâmetros (nome do processo, prioridade, estado, etc.). Sua criação permite a execução de outros aplicativos concorrentes ao programa chamador.

Sinais

A utilização de sinais é fundamental para o gerenciamento de processos, já que é uma maneira de notificar processos de eventos gerados pelo sistema operacional ou por outros processos, além de possibilitar a sincronização e comunicação entre processos.


Um ótimo exemplo da utilização de sinais é quando o usuário pressiona simultaneamente as teclas CTRL+C para interromper a execução de um programa. No momento em que as teclas são pres-sionadas, o sistema operacional sinaliza ao proces-so a ocorrência do evento e uma rotina própria de tratamento é executada.

Quer ver isso funcionando? Vá até o prompt de comando e execute o coman-do dir c:\windows /p para listar arquivos e pastas que estão na pasta windows no disco c. Para interromper a execução basta pressionar CTRL+C.


Para saber mais sobre Tipos de Processos, leia o Item 5.6 (p. 76-94) do livro de:


Através de ilustrações que auxiliam na compreen-são dos tipos de processos, os autores Francis e Luiz Paulo apresentam o assunto de forma clara e com exemplos de situações vividas por usuários.

Para saber mais sobre Tipos de Processos, leia o item 2.1.3 (p. 51-53) do livro de:



O livro apresenta o conceito das threads utili-zando o minix como um exemplo prático analisando suas chamadas de sistema e comandos utilizados.

PARA REFLETIR

Após o estudo deste conteúdo você é capaz de conceituar precisamente processo e thread? Reflita sobre a importância de um ambiente com múltiplos threads.

2.3 Comunicação entre Processos

Com o surgimento dos sistemas multiprogra-máveis, aplicações foram estruturadas de modo que partes diferentes do código do programa pudessem ser executados concorrentemente. Este tipo de apli-cação tem como base a execução cooperativa de múltiplos threads ou processos.

Aplicações Concorrentes

Essas aplicações em que partes diferentes de seu código são executadas concorrentemente são chamadas de aplicações concorrentes e em muitos casos é necessário que processos se comuniquem preferivelmente de uma maneira bem estruturada que não utilize interrupções.


Podemos destacar três questões a respeito da comunicação entre os processos. A primeira é a ma-neira como um processo pode passar informações para outro.

A segunda questão é certificar que dois ou mais processos não interfiram entre si quando estão em atividades críticas.

A terceira questão lida com o sequenciamento lógico dos processos quando se encontram em regi-ões críticas, exemplo, se o processo A produz dados e o processo B os imprime, B tem de esperar até que A tenha produzido algum dado antes de iniciar a impressão (TANEMBAUN; WOODHULL, 2000). Reflita a respeito disso e exponha no AVA outras questões a respeito da comunicação entre os processos.

Figura 24 - Dois processos querem acessar a memória compartilhada ao mesmo tempo.

Fonte - TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacio-nais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000, p. 54.


Condição de corrida

Quando um ou mais processos estão lendo ou gravando dados compartilhados e o resultado final depende de quem executa exatamente quando temos uma situação chamada condição de corrida (race conditions).

A parte do programa cujo processamento pode levar a uma condição de corrida é conheci-da como região crítica. Podemos então dizer que quando dois ou mais processos rodarem sua região crítica ao mesmo tempo temos uma condição de corrida.

Exclusão Mútua

Para evitar uma condição de corrida é neces-sário uma maneira de garantir que enquanto um processo esteja utilizando um arquivo ou variável compartilhado, os outros processos estão impe-didos de fazerem a mesma coisa. A isso dá-se o nome de exclusão mútua.

Uma solução para evitar uma condição de corrida deve garantir quatro condições: nenhum dos processos pode estar simultaneamente dentro de suas regiões críticas; nenhum processo fora de sua região crítica pode bloquear outro processo; nenhum processo deve esperar eternamente para entrar em sua região crítica e nenhuma suposição pode ser feita sobre as velocidades ou número de CPUs. Grave essas quatro condições.

Desativando as interrupções

Uma solução de hardware simples para o pro-blema da exclusão mútua é permitir ao processo desabilitar todas as interrupções antes de entrar em sua região crítica e as reabilitar após deixar a região crítica.


Como a CPU alterna de processos através de interrupções de relógio (ou outras interrupções), com essas interrupções desativadas a CPU não alter-nará de um processo para o outro, logo, ele poderá manipular a memória compartilhada sem a possibili-dade de outro processo intervir.

Apesar da garantia contra a condição de cor-rida os inconvenientes desta solução são grandes. Primeiro compromete seriamente a multiprograma-ção, já que a concorrência entre processos tem como base o uso de interrupções.

Outro problema grave é dar ao aplicativo do usuário o poder de desativar as interrupções. Supo-nha que um deles faça isso e não as ative mais.

E em um sistema de multiprocessamento? Pense o que ocorreria em um sistema com mais de uma CPU. Duas observações po-deriam ser feitas. Poderiam existir dois pro-cessos rodando cada um em um proces-sador distinto, jamais ocorrendo assim a exclusão mútua. E um grande cuidado de-veria ser tomado ao inibir as interrupções, pois poderia desativar as interrupções de um processador que não estaria envolvido com o processamento de processos com potencial para exclusão mútua.

Variáveis de Travamento

Uma solução de software seria a utilização de uma variável única compartilhada, definida inicial-mente como 0. Se um processo for entrar em sua região crítica, ele verifica se a variável possui o valor 0. Caso positivo, ele a define como 1 e entra em sua região crítica. Se a variável já estiver em 1, o proces-so deve aguardar até ele se tornar 0. Esta variável é conhecida como variável de bloqueio ou travamento.


Para compreender o inconveniente desta solução basta rever o exemplo dado sobre o spo-oler de impressão. Consegue explicar qual seria o problema? Bom, se o processo A não produzir antes os dados necessários, o processo B não terá o que imprimir.

Alternância Estrita

Basicamente faz um teste contínuo de uma variável de turno até que um determinado valor a permita entrar em sua região crítica. Imagine uma variável inicialmente definida como 0. Um proces-so A3 lê esta variável, verifica que seu valor é 0 e entra na sua região crítica. O processo B4 também verifica que ele é 0 e entra em uma estrutura de laço testando a variável continuamente até que ela se torne 1.

Quando o processo A sai de sua região críti-ca, ele define a variável como 1, permitindo assim que o processo B entre em sua região crítica.

Testar uma variável continuamente até que determinado valor apareça é conhecido como es-pera ativa. Normalmente é uma solução evitada por desperdiçar tempo da CPU.

Agora imagine que o processo B termine rapi-damente seu trabalho na região crítica e então am-bos os processo estão em suas regiões não-críticas com a variável definida em 0. Agora o processo A roda toda sua estrutura de laço rapidamente vol-tando para sua região não-crítica com a variável configurada para 1. Nesse instante, o processo B termina sua tarefa na sua região não-crítica e volta ao topo de sua estrutura de laço, mas não tem permissão para entrar em sua região crítica, porque

3 Para o processo A, quando a variável é 0 ele entra em sua região crítica e ao sair, confi gura a variável para 1.

4 Para o processo B, quando a variável é 1 ele entra em sua região crítica e ao sair, confi gura a variável para 0.


a variável está definida como 1. E ambos os proces-sos estão em suas regiões não-críticas.

Na prática, esta solução de alternância não é uma boa sugestão quando um dos processos é muito mais rápido que o outro. Você saberia dizer qual das quatro condições para evitar uma condição de corrida esta situação viola? Coloque sua resposta no AVA e discuta sobre ela com outros alunos.

Solução de Peterson

Esta solução combina a ideia de variável de travamento com variável de turno. Consiste em dois algoritmos distintos para permitir o processo entrar em sua região crítica e informar que deixou sua região crítica.

Antes de entrar em sua região crítica, cada processo chama uma função com seu próprio nú-mero de processo, 0 ou 1, como parâmetro. Essa chamada causará espera se for necessário, até que seja seguro entrar. Após o término das atividades em sua região crítica, o processo chama uma nova função para indicar que finalizou e permitir que ou-tro processo entre.

Agora suponha que os dois processos cha-mem a primeira função quase simultaneamente, ambos armazenarão seu número de processo na variável turno. Qualquer que seja, o armazenamen-to feito por último é o que conta, o primeiro será perdido. Isso pode fazer com que um processo en-tre em uma estrutura de laço e não entre em sua região crítica.Instrução TSL


Muitos computadores possuem uma instrução chamada Test and Set Lock (TSL – testa e configura o bloqueio) que permite ler uma variável, armaze-nar seu conteúdo em outra área e atribuir um novo valor à mesma variável.

Sua grande característica é ser executada sem interrupção, ou seja, suas operações de leitura e escrita são garantidas como sendo indivisíveis. Assim, é garantido que dois processos não estejam em sua região crítica ao mesmo tempo.

Sleep e Wakeup

As soluções TSL e de Peterson possuem a mesma característica de utilizar a espera ativa, que além de desperdiçar tempo da CPU, pode ter efeitos inesperados.

Na solução Sleep (dormir) e Wakeup (acordar), Sleep é uma chamada de sistema que causa o bloqueio do processo que fez a chamada, ele é suspenso até que outro processo o acorde. A chamada Wakeup tem um único parâmetro, o processo a ser acordado. Como alternativa às soluções TSL e de Peterson, Sleep e Wakeup não geram a espera ativa e têm um único parâmetro, um endereço de memória usado para coincidir os Sleep´s com os Wakeup´s5.

Semáforos

O semáforo é uma variável inteira, não nega-tiva, que usa duas operações: Down e Up. Podem ser classificados como binários, os quais só podem assumir os valores 0 e 1, e contadores, que pode ser igual a 0 ou qualquer número positivo.

A operação Down verifica se o valor do se-máforo é maior que 0. Se verdadeiro, então seu

5 Veja na p. 57 do livro: TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas opera-cionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000. O Problema dos Produtores e Consumidores.


valor é decrementado e o processo continua sua execução, senão, o processo que executou a operação Down é posto para dormir.

Essa solução utiliza uma relação atômica (uma vez iniciada uma operação de semáforo, ne-nhum outro processo pode acessá-lo até que tenha finalizado). Isso é essencial para evitar a condi-ção de corrida. Quando usa um caixa automático de banco, é um processo atômico? Uma operação bancária precisa ser realizada como um processo atômico, Já pensou ao sacar dinheiro em um caixa automático o valor ser debitado em sua conta, mas o processo ser interrompido antes de lhe entregar o dinheiro?

A operação Up incrementa o valor do se-máforo e acorda um eventual processo que este-ja dormindo naquele semáforo. Também é uma operação6 atômica.

Monitores

O monitor é um mecanismo estruturado (ao contrário dos semáforos que são considerados não estruturados) formado por procedimentos e variá-veis encapsulados dentro de um módulo. Sua ca-racterística mais importante é o fato de somente um processo poder executar um dos procedimentos do monitor em um determinado instante.

Quando algum processo faz uma chamada a um desses procedimentos, o monitor verifica se já existe outro processo executando algum proce-dimento do monitor, caso exista, o processo fica aguardando a sua vez em uma fila de entrada.Figura 25- Estrutura do Monitor

6 Veja na p. 59 do livro: TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas opera-cionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000. Como resolver o Problema dos Produtores e Consu-midores utilizando semáforos.



7 Veja na p. 64 do livro: TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000; problemas clássicos de comunicação entre processos.

Troca de Mensagens

É um mecanismo de sincronização e comu-

nicação entre processos. Para que ele ocorra, deve

existir um canal de comunicação entre os proces-

sos, podendo ser um link de uma rede de compu-

tadores ou um buffer.

O sistema operacional possui um sistema de

mensagem que suporta esse mecanismo sem que

exista a necessidade do uso de variáveis compar-

tilhadas.

É uma maneira de solucionar um dos proble-

mas com monitores e semáforos em sistemas com

múltiplas CPUs distribuídas, cada uma com sua

própria memória privada, conectadas por uma rede

local, já que os monitores e semáforos foram proje-

tados para resolver o problema de exclusão mútua7

em CPUs que têm acesso a uma memória comum.



Para saber mais sobre Comunicação entre Processos leia o Capítulo 7 (p. 95-62) do livro de:


As comunicações entre os processos e sua sincro-nização são apresentadas em forma de diagrama, estrutura dos códigos da solução e com dados his-tóricos de seus criadores.

Para saber mais sobre Comunicação entre Processos leia o item 2.2 (p. 53-68) do livro de:


A análise das soluções criadas para as comunica-ções entre processos são apresentadas com o es-tudo dos códigos de cada solução e da apresenta-ção das vantagens e desvantagens comparando-as umas com as outras.

PARA REFLETIR

Reflita sobre a decisão dos programadores e proje-tistas em definir soluções de concorrência entre pro-cesso por meio de hardware, software ou soluções híbridas.


2.4 Escalonamento de Processos

Como vimos no item anterior, os múltiplos processos podem permanecer na memória principal compartilhando o uso da CPU. Neste compartilha-mento, critérios devem ser estabelecidos para determinar qual processo será escolhido para utilizar o processador.

Esses critérios compõem a política de esca-lonamento (ou agendamento) que é a base da ge-rência do processador em um sistema operacional. A rotina que toma essa decisão é chamada de es-calonador (ou agendador) e o algoritmo utilizado é conhecido como algoritmo de escalonamento (ou agendamento).

Dentre os principais critérios a serem levados em consideração em uma política de escalonamento podemos citar:

O tempo de uso da CPU que determina a eficiência do agendador em manter a CPU ocupada 100% do tempo;

A imparcialidade que dará a cada processo um tempo justo de utilização da CPU;

O tempo de resposta que deve ser minimiza-do ao máximo para a interatividade com usuários;

O tempo que um processo leva desde sua criação até o seu término – Turnaround;

O número de processos executados em um determinado intervalo de tempo – Throughput.

O tempo de espera em que um processo per-manece na fila de pronto (estado ready) durante seu processamento, aguardando para ser executado.

Acredita ser possível atender a todos os critérios ao mesmo tempo? Pense a res-peito e coloque sua opinião no AVA para discussão.


Escalonamento Preemptivo e Não-Preemptivo

• O escalonamento preemptivo tem como principal característica a suspensão tem-porária pelo sistema operacional de pro-cessos que são logicamente executáveis, ou seja, a mudança de seu estado de ro-dando (running) para o estado de pronto (ready).

• O escalonamento não-preemptivo é quan-do um processo está em execução e ne-nhum evento externo pode ocasionar a perda de uso do processador. Ele só sai do estado rodando (running) caso termine seu processo ou execute uma instrução do próprio código para o estado de bloqueio (wait).

O que é mais eficiente? Que um processo possa ser suspenso em um instante qual-quer para que outro possa ser executa-do, ou permitir que um processo execute o quanto quiser até terminar sua tarefa? Pense a respeito.

Algoritmos de Escalonamento

FIFO - First-In-First-Out No escalonamento FIFO (primeiro a entrar pri-

meiro a sair), o processo que chegar primeiro ao estado de pronto (ready) é escalonado para a exe-cução. Quando o processo em execução vai para o estado bloqueado (wait), o primeiro processo da fila é o próximo a ser escalonado.


Figura 26 - Escalonamento FIFO

Fonte - MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, p. 138.

Quando os processos saem do estado de bloqueado (wait), todos entram no final da fila de pronto (ready). O escalonamento FIFO é do tipo não-preemptivo e inicialmente implementado em siste-mas monoprogramáveis com processamento batch.

Round Robin (Circular)

Atribui intervalos de tempos iguais a cada processo (quantum). O processo que acabou de sair da CPU vai para o final da fila. Um problema fácil de identificar é um tempo de resposta ruim se o quantum for grande demais e um desperdício de CPU se for muito pequeno.

Figura 27 - (a)Lista de processos executáveis (b) Lista de processos executáveis depois que B utiliza todo seu quantum

Fonte - TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas operacionais: projeto e implemen-tação. 2. ed. Porto Alegre: Bookman, 2000, p. 70.


Escalonamento por Prioridade

Neste modelo de escalonamento, cada pro-cesso é associado a uma determinada prioridade dentre os processos que estão no estado de pronto. Aquele com maior prioridade será escalonado.

Uma forma de evitar o monopólio de um pro-cesso de alta prioridade é decrementar sua priori-dade a cada interrupção de relógio, de forma que fique mais baixa do que o processo de maior prio-ridade da fila.

Escalonamento Circular com Prioridades

Implementa o conceito de fatia de tempo (time-slice - visto no item 1.2) e de prioridade de execução associada a cada processo. A principal vantagem desse escalonamento é permitir o melhor balanceamento do uso da CPU, com a possibilidade de diferenciar o grau de importância dos processos.

Neste tipo de escalonamento, um processo permanece no estado de execução até que termine seu processamento, passe para o estado de blo-queio (wait) voluntariamente, ou sofra uma pre-empção por tempo ou prioridade.

Múltiplas Filas

Neste modelo de escalonamento existem diversas filas de processos no estado de pronto (ready), cada uma com uma prioridade específica (e não o processo).

Os processos são associados às filas em fun-ção de suas características, como tipo de processa-mento, importância para a aplicação, etc. A princi-pal vantagem de múltiplas filas é a convivência de mecanismos de escalonamentos diferentes em um mesmo sistema operacional.


Escalonamento por Múltiplas Filas com Realimentação

A diferença para o escalonamento por múlti-plas filas é que os processos podem trocar de fila durante seu processamento. A grande vantagem é permitir ao sistema operacional identificar dinami-camente o comportamento de cada processo, dire-cionando-o para a fila adequada ao longo de seu processamento.

Escalonamento SJF – Shortest-Job-First

No escalonamento shortest-job-first (menor job primeiro) o processo no estado de pronto (re-ady) que precisar do menor tempo de processador para terminar seu processamento é selecionado. É um modelo usado estritamente para sistemas batch.

Figura 28 - Escalonamento SJF


Enquanto o job não termina, o processador não é liberado.


Escalonamento Garantido

Neste modelo de escalonamento a responsa-bilidade da interrupção do processo em execução não é do sistema operacional. Ele consiste em uma cooperação entre processos para a liberação de uso do processador.

Cada usuário (n) terá aproximadamente 1/n de tempo de uso do processador, ou seja, é calcu-lado o tempo que o usuário realmente deve mere-cer, dividindo o tempo decorrido de sua atividade pelo número de usuários (n).

Escalonamento por Sorteio

A ideia básica é dar bilhetes de loteria de processos aos vários recursos do sistema, como tempo de CPU (TANEMBAUN; WOODHULL, 2000). Quando um escalonamento tiver de ser feito, um bilhete de loteria é escolhido randomicamente e o processo que possuir esse bilhete recebe o recurso.

Na verdade, é um sorteio um tanto quanto tendencioso, já que processos mais importantes podem receber bilhetes extras e processos coope-rativos podem trocar de bilhetes.

Escalonamento de Tempo Real

No escalonamento de tempo real é garantida a execução de processos dentro de rígidos limites de tempo, sem o risco de comprometer a aplicação. Neste modelo, é levada em consideração a impor-tância relativa de cada tarefa na aplicação.

No escalonamento para sistemas de tempo real a prioridade deve ser estática e não deve haver o conceito de fatia de tempo (time-slice). Um bom exemplo de programas de tempo real é o controle de tráfego aéreo.


Escalonamento de Dois Níveis

Em todos os algoritmos de escalonamento analisados, usamos a premissa de que todos os processos executáveis estavam na memória prin-cipal. Se a memória principal não for suficiente, alguns processos terão de permanecer em disco (todo o processo ou parte dele).

Como o tempo de troca para carregamento e execução de um processo do disco é muito maior que um processo já carregado na memória principal, utiliza-se um escalonador de dois níveis, onde um agendador de nível mais alto é chamado para remover os processos que estiverem por tempo suficiente na memória e carregar processos que estiverem muito tempo no disco.


Para saber mais sobre Escalonamento de Processos leia o Capítulo 8 (p. 135-152) do livro de:


Em seu livro, Francis e Luiz Paulo ilustram os algo-ritmos de escalonamento exemplificando as estru-turas computacionais onde são encontrados.

Para saber mais sobre Escalonamento de Processos leia o item 2.4 (p. 69-75) do livro de:



As analogias feitas por Tanembaun e Woodhull em seu livro tratando do assunto de agendamento de processo tornam sua compreensão mais fácil e os exemplos em códigos mais claros.

PARA REFLETIR

Com base no que aprendeu sobre os tipos de siste-mas operacionais e o escalonamento de processos, reflita sobre o melhor algoritmo para cada tipo de sistema operacional.

RESUMO

No conteúdo 2.1 vimos juntos a diferença sutil en-tre processo e programa, os estado de um processo e a importância que o gerenciamento de processo tem dentro do contexto de sistemas operacionais. Na sequência, foram apresentados os Tipos de pro-cessos, suas características e vantagens e desvan-tagens em suas implementações.Caminhando pelo conteúdo 2.3, conhecemos as di-ferentes soluções para permitir o compartilhamento de recursos entre processos, seus cuidados e van-tagens quando aplicados em diferentes estruturas computacionais.

Por fim, no 2.4, apresentamos os diferentes algorit-mos de escalonamento para a utilização do proces-sador e suas características em ambientes opera-cionais diversos. A compreensão desses conceitos é de fundamental importância para iniciarmos o estudo dos demais gerenciamentos que iremos ver no próximo tema.

FUNCIONAMENTO DE SISTEMAS OPERACIONAIS

Parte 2

Funções essenciais de um Sistema Operacional3

Neste texto trabalharemos juntos sobre as principais gerências do sistema operacional além do processador, já que a execução do processo é somente uma parte do funcionamento do sistema

Ao final deste tema você será capaz de compreender melhor como os processos são armazenados na memória, como utilizam o disco nessa tarefa e como o sistema lida com os dispositivos de entrada e saída, além do gerenciamento de múltiplos processadores.


3.1 Gerência de Múltiplos Processadores

Como visto no item 1.2, os sistemas com múl-tiplos processadores são arquiteturas que possuem uma ou mais CPUs interligadas e que trabalham em conjunto na execução de tarefas independentes ou no processamento de uma mesma tarefa.

Com os sistemas de múltiplos processadores passa a ser possível o conceito de paralelismo, no qual se pode executar mais de um programa ao mesmo tempo.

Basicamente a idealização deste sistema se deve, em grande parte, ao alto custo de desen-volvimento de processadores mais velozes. Outra justificativa são aplicações que requerem um alto poder computacional e com múltiplos processado-res é possível reduzir bastante o tempo de proces-samento dessas aplicações.

As empresas reconheceram nesse tipo de sistema uma maneira de aumentar a confiabilida-de, a disponibilidade e a escalabilidade, além da possibilidade do balanceamento de carga e suas aplicações.

Hoje até mesmo nos computadores pessoais temos a vantagem do multiprocessamento devido à redução de custo dessas arquiteturas e à evolução dos sistemas operacionais, que passaram a ofere-cer suporte a múltiplos processadores.

Com certeza você já ouviu falar dos proces-sadores dual core. Um processador de dois núcleos permite o paralelismo? Pense sobre isso e divulgue suas conclusões no AVA para discussão.

Vantagens dos Sistemas de Múltiplos ProcessadoresNo item 1.2 de nosso estudo, vimos alguns

conceitos que definem as vantagens de um sistema de múltiplos processadores, veremos agora esses conceitos com mais detalhes.

91Tema 3 | Funções essenciais de um sistema operacional

Desempenho

Apesar de não existir uma relação linear, se novos processadores forem adicionados à arquite-tura do computador, melhor será seu desempenho, pois reduzirá o tempo de resposta e o tempo gasto no processamento dos programas, e aumentará o throughput8 do sistema (número de processos exe-cutados em um determinado intervalo de tempo).

A melhora do desempenho com múltiplos processadores pode acontecer em dois níveis. Pri-meiro porque permitirá a execução simultânea de processos independentes (throughput). Segundo, porque múltiplos processadores permitem o pro-cessamento paralelo (execução de uma mesma ta-refa por vários processadores simultaneamente). É importante ressaltar que apenas as aplicações con-correntes oferecem ganhos reais com o aumento do número de processadores.

Custo X Desempenho

Por mais poderosos que sejam, sistemas com um único processador apresentam limitações de desempenho inerentes à sua construção (proble-mas de superaquecimento) e arquitetura, devido as limitações de comunicação nos barramentos que ligam a CPU à memória principal (e outros recursos do computador).

Será que partiu daí a ideia de se construir um processador com mais de um núcleo?

Além disso, o custo de desenvolvimento de uma CPU de alto desempenho é muito elevado, o que faz com que sistemas com múltiplos pro-cessadores que utilizam CPUs convencionais e de baixo custo ofereçam alto desempenho a custos aceitáveis.

8 Vimos sobre este assunto no item 2.4 e m escalonamento de processos.


Escalabilidade

A capacidade de adicionar novas CPUs ao hardware do sistema é chamada de escalabilidade. Essa característica é inerente aos sistemas de múl-tiplos processadores.

Balanceamento de Carga

O conceito de balanceamento de carga segun-do Machado e Maia (2007, p. 245), “a distribuição do processamento entre os diversos componentes da configuração, a partir da carga de cada proces-sador” que consequentemente gera uma melhoria no desempenho do sistema como um todo.

Disponibilidade e Tolerância a Falhas

Em um sistema com multiprocessadores, se uma das CPUs falhar, as demais podem assumir suas funções, embora com menor capacidade com-putacional, dando a ele uma maior tolerância a fa-lhas e uma maior disponibilidade9.

Desvantagens

Obviamente um sistema com múltiplos processadores também possui algumas desvan-tagens como problemas de comunicação e sincro-nização que devem ser resolvidos, já que vários processadores podem acessar as mesmas posições de memória ao mesmo tempo.

Uma das desvantagens é a complexidade de organizar os recursos (processadores, memórias e periféricos) de uma forma eficiente, que permita uma aceitável relação custo/benefício.

9 Disponibilidade é o número de minutos por ano que o sistema permanece em funcionamento de forma ininterrupta.


Outra desvantagem é que de acordo com o tipo de sistema, a tolerância contra as falhas men-cionadas anteriormente depende do sistema opera-cional e não somente do hardware, o que é difícil de ser implementado para garantir essa tolerância.

Sistemas com Multiprocessadores Simétricos

Os sistemas com multiprocessadores simétricos é uma evolução da organização assimétrica, em que somente um processador (mestre) pode executar os serviços do sistema operacional. Sempre que outro processador (escravo) precisar realizar um serviço do sistema operacional, deve requisitar ao processador mestre.

Acha possível o paralelismo em um sistema com multiprocessadores assimétricos? Pense sobre isso e divulgue suas conclusões no AVA para discussão.

Figura 29 - Um modelo de multiprocessador mestre-escravo.

Fonte - TANENBAUM, Andrew S. Sistemas operacionais modernos. 2. ed. Rio deJaneiro: Prentice Hall Brasil, 2007, p. 387.

Nos sistemas com multiprocessadores simé-tricos (SMP – Symmetric Multiprocessors) existem dois ou mais processadores compartilhando um único espaço de endereçamento e gerenciados por apenas um sistema operacional.


Figura 30 - Modelo de multiprocessador SMP


Essa arquitetura, também conhecida como UMA (Uniform Memory Access – Acesso à Memória Uniforme) tem como característica o tempo de acesso à memória ser uniforme, independente da localização física do processador.

Sistemas NUMA – Non-Uniform Memmory Access

Na arquitetura NUMA existem vários conjuntos, reunindo processadores e memória, compartilhando um mesmo sistema operacional e fazendo referência ao mesmo espaço de endereçamento, sendo cada conjunto conectado entre si através de uma rede de interconexão.

Em um sistema NUMA o tempo de acesso à me-mória RAM depende da localização física do proces-sador. Sua diferença básica com o sistema SMP está no desempenho das operações de acesso à memória.

No sistema NUMA, a memória principal é fisi-camente distribuída entre os vários processadores, no entanto, existe apenas um único espaço de endereçamento sendo compartilhado. Este modelo de memória é conhecido como memória compartilha-da distribuída (DSM – Distributed Shared Memory).


Por oferecer um menor custo e maior desempenho (além de uma maior escalabilidade de processadores), os sistemas NUMA são uma alternativa ao modelo SMP. Seu ponto negativo é a dificuldade em manter um nível de desempenho satisfatório, devido à existência de tempos de acessos bastante diferentes da memória RAM.

Clusters

Clusters são os nós conectados por uma rede de interconexão dedicada e de alto desempenho. Cada nó da rede possui seus próprios recursos (pro-cessadores, memória, dispositivos de entrada/saída e sistema operacional) e é chamado de membro do cluster.

Figura 31 - Exemplo de cluster



São sistemas fracamente10 acoplados onde a rede de interconexão é restrita aos membros do clus-ter e cada um possui seu próprio espaço de ende-reçamento. Contudo, para um usuário de um cluster é como se estivesse usando um sistema fortemente acoplado, ele não tem conhecimento do número de membros que compõem o cluster. Essa característica é conhecida como imagem única do sistema.

É possível um cluster ser composto por com-putadores com sistemas operacionais diferentes? Pense sobre isso e divulgue suas conclusões no AVA para discussão.

Sistemas Operacionais de Rede

Em um ambiente operacional de rede, cada sistema (host) possui seus próprios recursos de har-dware, sendo totalmente independente dos demais, interconectados por uma rede de comunicação de dados criando uma rede de computadores.

Os sistemas operacionais de rede são usados tanto em redes locais (LAN – Local Area Network), quanto em redes distribuídas (WAN – Wide Area Network). A princípio não existe um limite máximo para o número de hosts que podem fazer parte de uma rede de computadores.

10 Tratamos de sistemas fracamente e fortemente aco-plados no item 1.2 de nosso estudo.


Figura 32 - Rede de computadores

Fonte - Fonte: MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, p. 261.

A maioria dos sistemas operacionais de rede implementam o modelo cliente/servidor, no qual existe um ou mais servidores que oferecem servi-ços aos demais clientes da rede.

O melhor exemplo disso é a internet, em que o browser de um usuário funciona como um cliente que solicita informações e um servidor web atende a essas solicitações.

Sistemas Distribuídos

Os sistemas distribuídos são sistemas for-temente acoplados e sua diferença com os de-mais sistemas fracamente acoplados é a existência de um relacionamento mais forte entre seus com-ponentes.


Ele pode ser conceituado como um sistema fracamente acoplado na visão do hardware (pois seus componentes podem estar conectados em uma rede local ou através de uma rede distribuída), mas fortemente acoplado na visão do software, já que apresenta ao usuário uma imagem única do sistema.

Do ponto de vista do usuário, também possui a característica de imagem única do sistema.

Figura 33 - Sistema distribuído



Para saber mais sobre Gerência de Múltiplos Proces-sadores leia o Capítulo 13 (p. 243-264) do livro de:


Em seu livro, Francis e Luiz Paulo dedicam um capí-tulo inteiro à analise das características e compor-tamento dos sistemas com múltiplos processado-res, o que facilita o estudo das comparações entre seus diferentes tipos.


Para saber mais sobre Gerência de Múltiplos Proces-sadores leia o Capítulo 8 (p. 378-434) do livro de:

TANENBAUM, Andrew S. Sistemas operacionais moder-nos. 2. ed. Rio de Janeiro: Prentice Hall Brasil, 2007.

Tanenbaum trata a fundo as particularidades de um sistema com multiprocessadores e apresenta as situações encontradas em sistemas distribuídos, como a internet, e analisa suas atuais soluções.

PARA REFLETIR

Se olhar para a evolução dos processadores para uso pessoal, sua velocidade de processamento foi crescendo até chegarmos a um limite próximo a 4 Ghz. Reflita o porquê disso e sobre a solução dada pelos fabricantes. Pense sobre isso e divulgue suas conclusões no AVA para discussão.


3.2 Gerência de Memória

Normalmente um computador possui uma pequena quantidade de memória cache volátil e muito rápida, centenas (ou poucos milhares) de megabytes de memória principal volátil e de ve-locidade média (RAM – Random Access Memory) e centenas de gigabytes de armazenamento em dis-co, não volátil e de lento acesso.

Uma das tarefas do sistema operacional é ge-renciar como essa hierarquia de memória é usada controlando as partes livres e em uso, alocando e liberando espaço para processos e gerenciando a troca entre a memória principal e o disco quando necessário.

Em geral, os programas são armazenados no disco (memória secundária) por ser um meio não volátil e de grande capacidade de armazenamento. Como o processador só executa instruções locali-zadas na memória principal, o sistema operacional deve transferir programas do disco para a memória RAM antes de serem executados.

A gerência de memória deve procurar manter o maior número de processos na memória princi-pal, para maximizar o compartilhamento do pro-cessador e demais recursos computacionais, já que o tempo de acesso à memória secundária é muito maior que o tempo de acesso à memória RAM.

Na ausência de espaço livre na memória prin-cipal, o sistema operacional realiza uma transferên-cia temporária de processos residentes na memória RAM para o disco, liberando espaços para novos processos. Este processo é conhecido como Swap e trataremos sobre ele com mais detalhes mais adiante.


Monoprogramação sem Troca ou Paginação

Neste modelo de organização, a memória prin-cipal é subdividida em duas áreas, uma para o siste-ma operacional e outra para o programa do usuário.

Figura 34 - Alocação contígua simples


Quando o sistema está organizado dessa ma-neira, somente um processo pode estar rodando por vez. Quando o processo termina, o sistema operacional exibe um aviso de comando e espera um novo comando.

Técnica de Overlay

Uma solução encontrada para o limite do ta-manho da área da memória principal é dividir o programa em módulos, de forma que seja possível a execução independente de cada módulo, utilizan-do uma mesma área de memória. Esta técnica é conhecida como overlay.


A definição das áreas de overlay é função do programador e exige muito cuidado, devido à pos-sibilidade de transferência excessiva dos módulos entre a memória principal e o disco.

Figura 35 - Técnica de Overlay


Multiprogramação com Partições Fixas

Nos primeiros sistemas multiprogramáveis, a memória era dividida em n partições, cujo tamanho era estabelecido na fase de inicialização do sistema em função do tamanho dos programas que seriam executados.

Inicialmente os aplicativos só podiam ser carregados em uma partição específica, mesmo se outras estivessem disponíveis. Os códigos desses aplicativos eram conhecidos como código absoluto.

Com o tempo, o código gerado deixou de ser absoluto e os programas puderam ser executados a partir de qualquer partição passando a ser conhe-cido como código relocável.


Para controlar sobre quais partições estão alocadas, o sistema operacional mantem uma tabela com o endereço inicial de cada partição, seu tamanho e se está em uso.

Figura 36 - Alocação particionada estática


Multiprogramação com Partições Dinâmicas

A alocação particionada dinâmica eliminou o conceito de partições de tamanho fixo. Nesse mo-delo, cada programa utiliza o espaço necessário usando essa área como sua partição, não ocorren-do assim o problema da fragmentação interna.

Mas neste caso um tipo de fragmentação di-ferente começará a ocorrer. No momento em que os programas forem se encerrando, surgirão espa-ços cada vez menores na memória, não permitindo o ingresso de novos programas. Esse problema é chamado de fragmentação externa.

Estratégias de Alocação de Partições

Basicamente três estratégias são utilizadas pelos sistemas operacionais para evitar ou diminuir o proble-ma da fragmentação externa, determinando em qual área livre um programa será carregado para execução.


Best-fit - nessa solução, a partição em que o programa deixa o menor espaço sem utilização é a escolhida. Uma desvantagem nesse caso é o aumen-to da fragmentação da memória, pois cada vez mais surgirão pequenas áreas não adjacentes na memória.





First-fit – Nesse modelo é alocado o primeiro bloco de memória, grande o suficiente para receber o programa. Das três estratégias, esta é a mais rá-pida, consumindo menos recursos do sistema.


Worst-fit – Nessa estratégia, a partição escolhida é aquela que deixa o maior espaço sem utilização. Essa técnica deixa espaços livres maiores, o que permite um maior número de pro-gramas utilizar a memória e diminui o problema da fragmentação.

Figura 39 - Estratégias para a escolha da partição


11 Gera a partir de um ou mais módulos-objeto um programa executável pelo sistema opera-cional.

Apesar da técnica First-fit ser a mais rápida, você acredita que é a mais efi-ciente? Pense sobre isso e divulgue suas conclusões no AVA para discussão.

Realocação e Proteção

A multiprogramação cria dois problemas es-senciais que é a realocação e proteção. Quando um programa é vinculado a um endereço o link-editor11 deve saber em que endereço o programa deve começar na memória.

Mas e se o endereço do programa apontar para um endereço que o sistema operacional estiver usando?


A realocação de memória acontece na hora em que o programa é carregado, mas ela já é pre-vista no código binário do programa.

Uma solução seria modificar as instruções enquanto o programa é carregado na memória, e para isso, o link-editor deveria incluir no progra-ma binário uma lista (ou mapa de bits) informando quais palavras do programa são endereços a serem realocados e quais não o são.

Mas essa realocação não resolve o problema da proteção. Não é possível que um programa leia ou escreva em qualquer lugar da memória.

Como os programas nesse tipo de sistema utilizam endereços absolutos de memória, não há como impedir que um programa crie uma instrução que lê ou grave qualquer palavra na memória.

Nos sistemas multiusuários não é permitido que processos leiam e escrevam em partições de memórias alocados em outro processo.

Uma solução alternativa para ambos os problemas é disponibilizar dois registradores especiais de hardware, conhecidos como registrador de base e registrador de limite.

Quando um processo é agendado, o registra-dor de base é carregado com o endereço do início de sua partição e o registrador de limite com seu comprimento. Todo o endereço de memória gerado tem o registrador de base automaticamente adi-cionado a ele próprio antes de ser enviado para a memória.

Os endereços no registrador de limite tam-bém são verificados para ter certeza de que eles não tentarão endereçar memória fora da partição atual. O hardware protege os registradores de base12 e limite para que programas de usuários não o modifiquem.

12 O PC-XT da IBM (com o processador 8088) empregava uma versão mais fraca desse esquema.


Swapping (Troca)

Eventualmente não existe memória principal disponível para armazenar todos os processos atu-almente ativos. Os processos que excedem a capaci-dade de memória RAM são então mantidos no disco e trazidos de lá para a execução dinamicamente.

O swapping é uma técnica utilizada para pro-gramas que aguardam por memória principal livre para serem executados. O sistema escolhe um pro-cesso residente e o transfere da memória principal para a memória secundária (swap out), normalmen-te o disco. Depois o processo é levado de volta para a memória principal (swap in) e pode retomar sua execução.

Figura 40 - Troca de dois processos usando um disco como armaze-namento auxiliar

Fonte - SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas Operacionais com Java - conceitos e aplicações. Tradução da 6. ed. Rio de Janeiro: Campus, 2005, p.185.

O conceito de swapping permite um maior compartilhamento da memória principal. O grande inconveniente é tempo gasto nas operações de


entrada/saída. Em situações em que existe pouca memória principal disponível, o sistema fica prati-camente dedicado às operações de swapping.

Com a técnica de swap, você acredita que se pode dizer que o limite de memória virtual é a capacidade livre do disco? Pense sobre isso e divul-gue suas conclusões no AVA para discussão.

Gerenciamento de Memória com Mapas de Bits

A memória atribuída dinamicamente deve ser gerenciada pelo sistema operacional e em geral existem duas maneiras de monitorar o uso da me-mória: mapas de bits e listas livres.

No modelo de mapas de bits a memória é dividida em unidades de alocação onde cada uma é representada por 1 bit no mapa de bits, que é 0 se a unidade está livre e 1 se estiver ocupada.

No mapa de bits o monitoramento das pala-vras de memória em uma quantidade fixa de me-mória é bem simples, pois o tamanho do mapa depende somente do tamanho da memória e da unidade de alocação.

O inconveniente é quando se decide carregar na memória um processo com tamanho na ordem de k unidades, o gerenciador de memória precisa encontrar espaço disponível na memória procurando no mapa de bits uma sequência de k bits consecutivos de zeros, o que é uma operação bastante lenta.

Gerenciamento de Memória com Listas Encadeadas

Outra maneira de monitorar a memória é manter uma lista encadeada dos segmentos de me-mória alocados e livres, onde um segmento é um processo ou uma lacuna entre dois processos (TA-NEMBAUN; WOODHULL, 2000).


A classificação nesse modelo é vantajosa, pois quando um processo termina, ou está sendo envia-do para o disco, atualizar a lista é simples e direto.

Quando um processo encerra sua execução, normalmente possui dois vizinhos, que podem ser tanto processos como lacunas. Essa estrutura torna mais fácil localizar a entrada anterior e ver se uma fusão de lacunas é possível.


Para saber mais sobre Gerenciamento de Memória leia o Capítulo 9 (p. 155-169) do livro de:


Nesse capítulo específico do livro de Francis e Luiz Paulo, a gerência de memória é abordado de uma maneira bastante didática com ilustrações, compa-rações e exemplos de estruturas computacionais que a utilizam.

Para saber mais sobre Gerenciamento de Memória leia o Capítulo 4. (p. 210-217) do livro de:

TANENBAUM, Andrew S.; WOODHULL, Albert S. Sis-temas operacionais: projeto e implementação. 2. ed. Porto Alegre: Bookman, 2000.

Os modelos de gerenciamento de memória são apresentados baseados nos exemplos clássicos de implementação em computadores que participaram da evolução histórica da informática.


PARA REFLETIR

Muitas das implementações apresentadas acontece-ram devido ao fato de o custo de espaço em me-mória principal ser muito alto. Hoje temos micros desktops com capacidade de 4Gb de memória RAM. Acredita que deva existir uma preocupação atual com tipos de gerenciamento de memória como o swapping, por exemplo? Reflita sobre isso.

3.3 Memória Virtual

Um grande problema no gerenciamento de memória é que o programa e suas estruturas de dados estavam limitados ao tamanho da memória disponível. A solução era dividir o programa em pe-daços chamados overlays, visto no item anterior.

Os overlays eram mantidos em disco e eram levados para dentro e fora da memória pelo sistema operacional, dinamicamente, conforme necessário.

Uma das vantagens da memória virtual é pos-sibilitar a utilização de um número maior de pro-cessos compartilhando a memória principal, já que apenas pequenas partes de cada processo estarão residentes. O que acarreta também uma utilização mais eficiente do processador

Atualmente, a maioria dos sistemas imple-mentam a memória virtual.

Espaço de Endereçamento Virtual

O conceito de memória virtual é muito próximo do conceito de um vetor encontrado nas linguagens


de programação de alto nível. Quando um aplicativo faz referência a um elemento do vetor, não importa a posição de memória deste elemento. O compilador será responsável por gerar as instruções que imple-mentarão esse mecanismo de vetores.

Figura 41 - Espaço de endereçamentos virtual e real

Fonte - MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, p.173

Um aplicativo no ambiente de memória virtual não faz referência a endereços físicos de memória, somente a endereços virtuais que no momento da execução de uma instrução é convertido para um endereço físico.

O espaço de endereçamento virtual31 representa o conjunto de endereços virtuais que o processo pode endereçar, enquanto o conjunto de endereços reais que um processador pode referenciar se cha-ma espaço de endereçamento real.

13 Conforme visto no item 2.1 um processo é formado pelo contexto de hardware, contexto de software e pelo espaço de endere-çamento. Nos am-bientes de memória virtual, o espaço de endereçamento de um processo é conhecido como espaço de endereça-mento virtual.


Como não existe uma relação direta entre os endereços do espaço físico da memória principal com o endereçamento virtual, um aplicativo pode referenciar endereços virtuais que excedam os limi-tes da memória principal, com isso, os programas e suas estruturas de dados não estão mais limitados ao tamanho da memória física.

Isso é possível porque quando um programa é executado, somente uma parte de seu código fica residente na memória RAM, e o restante no disco até o momento de ser referenciado.

Mapeamento

O mecanismo utilizado para a tradução do endereço virtual para o endereço físico é chamado de mapeamento e com ele um programa não precisa estar necessariamente em endereços contíguos na memória principal para ser processado.

Figura 42 - Mapeamento



Cada processo possui seu espaço de ende-reçamento virtual como se possuísse sua própria memória. O mecanismo de tradução se encarrega de manter tabelas de mapeamento exclusivas para cada processo, que relaciona seus endereços virtu-ais às suas posições físicas na memória.

Atualmente, a tarefa de tradução dos en-dereços virtuais é feita por hardware junto com o sistema operacional. O dispositivo de hardware encarregado por esta tradução é a Unidade de Ge-renciamento de Memória (MMU – Memory Manage-ment Unit). Uma vez traduzido poderá ser utilizado pelo processador para o acesso à memória principal.

Paginação

Nessa técnica de gerência de memória virtual, o espaço de endereço virtual é dividido em unidades chamadas páginas e as unidades correspondentes na memória física são chamadas de molduras de páginas. Ambas devem possuir sempre o mesmo tamanho.

O mapeamento de endereço virtual em en-dereço físico é feito através de tabelas de páginas. Cada processo possui sua própria tabela de pági-nas e cada página virtual do processo possui uma entrada na tabela.

Quando um aplicativo é executado, as pági-nas virtuais são transferidas do disco para a memó-ria RAM e colocada nas molduras de página. Quan-do um programa se referir a um endereço virtual, o mecanismo de mapeamento localizará na entrada de tabela de páginas da tabela de processo (visto no item 2.1 – Implementação de um Processo) o endereço virtual da moldura de página no qual se encontra o endereço físico correspondente.


Política de Busca de páginas

O momento em que uma página deve ser car-regada para a memória é determinado pela política de busca de páginas. Basicamente as estratégias para isso são: paginação por demanda e paginação antecipada.

Quando as páginas dos processos são trans-feridas do disco para a memória RAM apenas quan-do são referenciadas, chamamos de paginação por demanda.

Quando o sistema transfere para a memória principal, além da página referenciada, outras pá-ginas que podem ou não ser necessárias ao longo do processamento, chamamos de paginação ante-cipada.

Consegue ver as implicações que podem surgir na paginação antecipada? Pense sobre isso e divulgue suas conclusões no AVA para discussão.

Políticas de Alocação de Páginas

Essa política determina quantas molduras de páginas cada processo pode manter na memória principal. Existem duas alternativas para isso: alocação variável e alocação fixa.

Na alocação fixa, cada processo tem um nú-mero máximo de molduras de página que pode ser utilizado durante a execução do aplicativo.

Na política de alocação variável, o número máximo de páginas alocadas ao processo pode va-riar durante sua execução em função de sua taxa de paginação e da ocupação da memória RAM.

E o que acontece se um programa precisar usar uma página que não está na memória e não há espaço para trazê-la da memória secundária?


Políticas de Substituição de Páginas

Pode acontecer de um processo atingir o seu limite de alocação de molduras de página e precisar transferir novas páginas para a memória principal, nesse caso, o sistema operacional deve selecionar qual das páginas alocadas deverá ser liberada. A este mecanismo chamamos de política de substituição de páginas.

Qualquer estratégia de substituição de páginas deve levar em consideração se a página foi ou não modificada antes de descartá-la, pois os dados arma-zenados na página podem ser perdidos. Neste caso, o sistema deverá gravá-la no disco antes de descartá-la, preservando seu conteúdo para uso futuro.

Este procedimento é conhecido como page out. Para tanto, o sistema mantém um arquivo de paginação para armazenar todas as páginas mo-dificadas e descartadas. Quando uma página for modificada novamente, ocorrerá um page in, sen-do transferida para a memória principal a partir do arquivo de paginação.

Figura 43 - Substituição de páginas



A política de substituição pode ser definida como local ou global.

A política de substituição local ocorre quando as páginas candidatas a realocação são as mesmas páginas do processo que gerou o page fault14.

Quando todas as páginas alocadas na me-mória RAM podem ser substituídas, chamamos de política de substituição global, e não depende do processo que gerou o page fault. Destacamos que páginas como as do núcleo do sistema são defini-das como bloqueadas e não podem ser realocadas.

Algoritmo de Substituição de Páginas

A decisão de quais páginas serão liberadas da memória RAM consiste no maior problema do gerenciamento de memória virtual por paginação.

O objetivo dos algoritmos de substituição de páginas é selecionar as molduras de página que te-nham as menores chances de serem referenciadas em um momento próximo.

Algoritmo Ótimo

Este algoritmo seleciona uma página para substituição que levará o maior intervalo de tempo para ser novamente utilizada ou que não será mais referenciada no futuro.

Algoritmo Aleatório

A possibilidade de as páginas alocadas na memória principal serem liberadas é a mesma para todas, não havendo nenhum critério em sua seleção.

14 Page fault é quando a página que contém o endereço referen-ciado não está na memória principal.


First-In-First-Out (FIFO)

Este algoritmo seleciona a página que está há mais tempo na memória principal (a primeira página que foi utilizada será a primeira a ser es-colhida).

Least-Frequently-Used (LFU)

Seleciona a moldura menos utilizada, ou seja, a página menos referenciada.

Least-Recently-Used (LRU)

É selecionada a página na memória RAM que está há mais tempo sem ser referenciada.

Not-Recently-Used (NRU)

Inicialmente seleciona as páginas que não foram utilizadas recentemente e não foram modi-ficadas, isso evita um page out. A seguir, substitui as páginas que não tenham sido referenciadas, po-rém modificadas. Utiliza um bit adicional conhecido como bit de referência.

FIFO com Buffer de Páginas

É uma combinação de uma lista de páginas alocadas com uma lista de páginas livres. A lista de páginas alocadas organiza as páginas alocadas há mais tempo na memória RAM no início da lista. A lista de páginas livres organiza as molduras de páginas livres da memória RAM, sendo que as pá-ginas livres há mais tempo estão no início da lista.


Sempre que um processo precisar alocar uma nova página, o sistema utiliza a primeira página da lista de páginas livres, colocando-a no final da lista de páginas alocadas.

FIFO Circular

Este algoritmo utiliza o FIFO como base, mas as páginas situadas na memória estão em uma estrutura circular. É o algoritmo implementado na maioria dos sistemas Unix.

Memória Virtual por Segmentação

Nesta técnica o espaço de endereçamento virtual é dividido em blocos de tamanhos diferen-tes chamados segmentos. Um programa é então dividido logicamente em sub-rotinas e estruturas de dados que são alocados em segmentos na me-mória principal.

Swapping em Memória Virtual

Nesta técnica de gerenciamento15, uma vez es-colhidos os processos, o sistema os retira da me-mória principal para o disco (swap out) onde são gravados em um arquivo de swap. Uma vez no disco as molduras ou segmentos alocados são liberados.

Posteriormente, os processos que foram retira-dos da memória devem retornar para a memória prin-cipal (swap in) para serem novamente executados.

15 Essa técnica foi vista no item 3.2 em gerência de memória.



Para saber mais sobre Memória Virtual leia o Capítulo 10 (p. 171-205) do livro de:


Em seu livro, Francis e Luiz Paulo dão uma grande ênfase à técnica de paginação expondo todas as suas características, vantagens e desvantagens

Para saber mais sobre Memória Virtual leia o Capítulo 4 (p. 139-196) do livro de:

TANENBAUM, Andrew S. Sistemas operacionais mo-dernos. 2. ed. Rio de Janeiro: Prentice Hall Brasil, 2007.

Tanenbaum descreve com propriedade as técnicas de gerenciamento de memória virtual, analisa suas implementações e seus impactos nos sistemas.

PARA REFLETIR

Em sistemas como o Linux o usuário pode definir o tamanho da partição no disco que será utilizada para swapping no momento da instalação. Reflita sobre qual seria a relação entre o tamanho da par-tição swap no disco e o tamanho da memória RAM do sistema.


3.4 Gerência de Dispositivos de Entrada e Saída

O gerenciamento dos dispositivos de entrada/saída é uma das funções mais complexas de um sistema operacional e sua implementação é estruturada em camadas.

Essas camadas são divididas em dois grupos, em que o primeiro trata os vários tipos de disposi-tivos do sistema de um mesmo modo, enquanto o segundo é específico para cada dispositivo.

Os dispositivos de entrada/saída são utiliza-dos para a comunicação entre o sistema e o mundo externo. São classificados como dispositivos de en-trada e/ou saída de dados. De um modo genérico, os dispositivos de entrada/saída podem ser dividi-dos nas seguintes categorias:

Consegue distinguir quais são os dispositivos de entrada e saída?

Dispositivo de Blocos - armazena informações em bloco de tamanho fixo, cada um com seu próprio endereço. Sua propriedade fundamental é poder ler ou escrever cada bloco independente dos outros blocos. Os discos são os dispositivos de blocos mais comuns.

Dispositivo de Caractere - libera ou aceita um conjunto de caracteres sem respeitar qual-quer estrutura de blocos. Não é endereçável e não possui nenhuma operação de posicionamento. Quase todos os demais dispositivos diferentes dos discos podem ser considerados dispositivos de caractere (mouse, teclado, impressora, etc.).

Dispositivo Sequencial ou Aleatório - trans-fere dados em uma ordem fixa que é definida pelo dispositivo sequencial, enquanto o usuário de um dispositivo aleatório pode instruir o dispositivo a buscar qualquer uma das posições disponíveis de armazenamento de dados.


Dispositivo Compartilhável ou Dedicado - Um dispositivo compartilhado pode ser usado ao mes-mo tempo por vários processos ou threads, um dis-positivo dedicado não.

Dispositivo Síncrono ou Assíncrono - Um dis-positivo síncrono executa as transferências de dados em tempos de resposta previsíveis. Um dispositivo assíncrono apresenta tempos de resposta irregulares.

Controladores de dispositivos

Os dispositivos de entrada/saída normalmente são compostos de um componente mecânico e um componente eletrônico. O componente eletrônico é a placa controladora responsável por manipular diretamente os dispositivos de entrada/saída. O componente mecânico é o dispositivo em si.

Sabia que as controladoras podem ser placas de expansão ou estarem presentes diretamente na placa mãe? Conhece o conceito on-board?

Figura 44 - Controladoras



Os controladores possuem registradores pró-prios. Por meio da escrita nesses registradores, o sistema operacional pode, por exemplo, comandar o dispositivo para entregar ou aceitar dados, ou exe-cutar alguma outra tarefa. A partir da leitura desses registradores, o sistema operacional pode descobrir o estado do dispositivo, se está preparado para aceitar um novo comando e assim por diante.

Além dos registradores de controle, muitos dispositivos têm um buffer de dados próprios que o sistema operacional pode ler ou escrever. É uma memória própria do controlador.

Os dados chegam em bloco de bytes e é nor-malmente montado, bit a bit, e armazenado no bu-ffer do controlador. O trabalho de um controlador de disco, por exemplo, é converter o fluxo serial de bits em um bloco de bytes e executar toda correção de erro necessária.

O controlador de um monitor de vídeo, tam-bém funciona como um dispositivo serial bit a bit. Ele lê bytes da memória que contém os caracteres para serem mostrados no vídeo e gera os sinais usa-dos para modular o feixe do tubo CRT do monitor.

Driver

Cada dispositivo de entrada/saída ligado ao computador precisa de um código específico do dispositivo para controlá-lo. Esse código é chama-do de driver e normalmente é escrito pelo fabricante do dispositivo e fornecido junto com ele.

Experimente desabilitar o driver de um disposi-tivo em seu micro. O dispositivo parou de funcionar?

A função do driver é receber da camada de subsistema de entrada/saída comandos gerais sobre os acessos aos dispositivos e traduzi-los para comandos específicos que poderão ser executados pelos controladores.


Figura 45 - Device Drivers


Os drivers fazem parte do núcleo do sistema operacional e em geral não são aptos a fazer cha-madas ao sistema, mas muitas vezes podem inte-ragir com o resto do núcleo.

Acesso Direto à Memória (DMA)

A CPU precisa endereçar os controladores dos dispositivos para poder trocar dados com eles. Ela pode requisitar dados de um controlador de en-trada/saída um byte de cada vez, mas desperdiça-rá com isso muito tempo de processamento, daí a utilização de uma estratégia de acesso direto à memória (DMA - Direct Memory Access).

O controlador DMA é um dispositivo de har-dware que pode fazer parte do controlador ou ser um dispositivo independente, e o seu uso impede que a CPU fique ocupada com a transferência do bloco para a memória.


A compreensão de seu funcionamento é mui-to simples. A CPU, através do driver do dispositivo, inicializa os registradores do controlador de DMA e fica livre para realizar outras tarefas. O controlador de DMA solicita ao controlador de disco a transferência do bloco do disco para seu buffer interno.

Terminada a transferência, o controlador de DMA transfere o bloco para o buffer de entrada/saída na memória principal e gera uma interrupção avisando à CPU que o dado já se encontra disponível na memória RAM.

Figura 46 - Operação de uma transferência com DMA

Fonte - TANENBAUM, Andrew S. Sistemas operacionais modernos. 2. ed. Rio de Janeiro: Prentice Hall Brasil, 2007, p.207.

Interrupções

O hardware da CPU possui uma linha de so-licitação de interrupção, que a CPU verifica após executar cada instrução. A CPU, quando detecta que uma controladora emitiu uma solicitação de interrupção, salva as informações de estado do processo atual e passa para a rotina de tratamento de interrupção.

Após determinada a causa da interrupção, a CPU realiza o processamento necessário solicitado pelo dispositivo e retorna ao estado de execução antes da interrupção.


Em um sistema operacional moderno, são necessários recursos mais sofisticados de tratamen-to de interrupções. Primeiro é preciso que exista a capacidade de adiar o tratamento de interrupções durante um processamento crítico. Segundo, é neces-sário que exista uma forma eficiente de transferir o controle para a rotina de interrupção adequada a de-terminado dispositivo sem ter de consultar todos eles para verificar qual dispositivo gerou a interrupção.

E, por fim, é desejável a existência de inter-rupções com múltiplos níveis, para que o sistema operacional possa distinguir entre interrupções de alta e baixa prioridade, e possa responder com o grau apropriado de urgência.

Nos hardwares de computadores modernos, essas situações são tratadas pela CPU e pelo har-dware da controladora de interrupções.

Discos Magnéticos

De todos os dispositivos de entrada/saída, os discos magnéticos merecem uma atenção especial por ser o principal dispositivo de armazenamento de dados utilizado pela maioria dos programas e pelo próprio sistema operacional.

O tempo utilizado para a leitura e gravação de um bloco de dados em um disco é função de 3 fatores: tempos de seek, tempo de latência rotacio-nal e tempo de transferência.

O tempo gasto no posicionamento do meca-nismo de leitura e gravação até o cilindro onde o bloco se encontra é chamado de tempo de seek. Normalmente é o fator de maior impacto de tempo no acesso a dados.

O tempo de latência rotacional é o tempo de espera até que o setor desejado esteja posicionado sob o mecanismo de leitura/gravação.


Figura 47 - Tempo de acesso

Fonte - MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007, p.238.

O tempo necessário para a transferência do bloco entre a memória principal e o setor do disco é chamado de tempo de transferência.

Se comparado ao número de instruções que o processador pode executar em um mesmo inter-valo de tempo, o tempo total das operações de entrada/saída é extremamente longo, pois todos esses fatores envolvem aspectos mecânicos.

Você conhece os HDs Ssd Flash? Eles teriam as mesmas características de seek e latência? Reflita sobre isso e divulgue suas conclusões no AVA para discussão.

Alguns sistemas gerenciadores de banco de dados (SGBD) implementam a técnica de copiar par-te dos dados do disco para a memória principal, uti-lizando uma área conhecida como disco RAM, com o objetivo de diminuir os tempos de seek e latência.


Alocação e Liberação de Dispositivos Dedicados

Determinados dispositivos, como um gravador de CD-ROM, por exemplo, podem ser usados por apenas um processo por vez. O sistema operacional deve ser capaz de avaliar as requisições de utilização do dispositivo, podendo aceitá-las ou rejeitá-las

Uma maneira simples de tratar essas requi-sições é fazer com que os processos executem chamadas ao sistema para a abertura de arquivos especiais, os quais são associados diretamente aos dispositivos.

Se o dispositivo não estiver disponível, a chamada falha. Com isso, o fechamento desse dis-positivo dedicado implica na liberação do mesmo.

Relatório de Erros

As falhas são muito mais comuns durante uma entrada/saída do que em qualquer outra situ-ação. Quando acontece um erro, o sistema opera-cional deve ser capaz de lidar com ele da maneira mais eficiente possível.

Apesar de muitos erros serem específicos de dispositivos e serem tratados por drivers apropria-dos, o modelo do tratamento de erro não depende do dispositivo.

Um tipo de erro de entrada/saída envolve er-ros de programação, como um processador tentar escrever em um dispositivo de entrada, ou ler a partir de um dispositivo de saída.

Outros tipos de erros são o fornecimento de um endereço inválido de buffer, ou a especificação de um dispositivo inválido, por exemplo, o acesso ao disco 2 quando o sistema só possui 1 disco.

O comportamento diante desses erros é sim-ples, enviar de volta ao processo chamador um código de erro.


Outra classe de erros são aquelas que en-volvem falhas reais de entrada/saída, como por exemplo, tentar escrever em um bloco de disco da-nificado ou ler a partir de uma webcam desligada. Nesses casos, é responsabilidade do driver deter-minar o que fazer.

E se ele também não souber o que fazer?

Se o driver não souber como proceder, ele poderá repassar o problema de volta ao software do dispositivo e o que ele fará irá depender do ambiente e da natureza do erro.


Para saber mais sobre Gerência de Dispositivos de En-trada e Saída leia o Capítulo 5 (p. 201-279) do livro de:

TANENBAUM, Andrew S. Sistemas operacionais moder-nos. 2. ed. Rio de Janeiro: Prentice Hall Brasil, 2007.

Tanenbaum detalha o funcionamento de cada um dos principais dispositivos de entrada/saída analisando a fundo seus algoritmos de manipulação de dados, tratamento de erros, impactos no sistema, etc.

Para saber mais sobre Gerência de Dispositivos de Entrada e Saída leia o Capítulo 12 (p. 284-305) do livro de:

DEITEL, Paul; DEITEL, Harvey; CHOFFNES, David. Sis-temas Operacionais. 3. ed. Prentice Hall Brasil, 2005.


Em seu livro, Paul e Harvey apresentam uma visão mais genérica do sistema no trato com os dispositi-vos de entrada/saída mostrando as características, problemas e soluções envolvidas nessa relação.

PARA REFLETIRComo se sabe os dispositivos de entrada/saída cor-responde a um grande gargalo no desempenho do processamento principalmente devido ao fato de seus componentes mecânicos. Mas o que dizer so-bre dispositivos como Flash-memory (pen drive)? Reflita sobre isso.

RESUMO

No conteúdo 3.1 vimos juntos as particularidades no gerenciamento de múltiplos processadores, suas vantagens, desvantagens, características e aplicações.

Já no 3.2, aprendemos sobre a importância do ge-renciamento da memória, já que é o local onde os dados aguardam para serem processados pela CPU. Seguindo com nossos estudos, vimos no conteúdo 2.3 a solução para o espaço insuficiente na memória principal, apresentado através do gerenciamento da memória virtual.


Por fim, no 2.4, percebemos o impacto de desem-penho que os dispositivos de entrada/saída cau-sam no sistema e as soluções existentes em seu gerenciamento para diminuir esse impacto. O con-junto do conhecimento dos gerenciamentos visto neste tema será de crucial importância no assunto de segurança que será tratado no tema a seguir.

Segurança de Sistemas Operacionais4

Neste texto trabalharemos juntos sobre os princípios existentes de armazenamento e organização dos arquivos, já que a partir daí podemos compreender as diversas regras de segurança existentes em um sistema operacional.

Ao final deste tema você será capaz de compreender diversas diretrizes de segurança utilizadas nos sistemas operacionais e conhecerá situações particulares de dois grandes sistemas operacionais: Linux e Windows.


4.1 Sistemas de Arquivo

A parte do sistema operacional responsável por gerenciar os arquivos é conhecida como sis-temas de arquivos e este gerenciamento deve ser feito de maneira a facilitar o acesso dos usuários a seu conteúdo, sendo feito de forma uniforme independente dos diferentes dispositivos de arma-zenamento.

O sistema de arquivos consiste em duas partes distintas: um conjunto de arquivos, cada qual armazenando dados correlatos e uma estrutura de diretório, que organiza e fornece informações sobre todos os arquivos do sistema.

Em um ambiente onde múltiplos usuários podem ter acesso aos arquivos é imprescindível que o sistema de arquivos implemente mecanismos que proporcionem a proteção de arquivos para controlar quem irá acessá-los e de que forma.

Como você protegeria seus arquivos con-tra o acesso de estranhos? Pense sobre isso e divulgue suas conclusões no AVA para discussão.

Arquivo

Um processo precisa ler e gravar grande vo-lume de dados em dispositivos de armazenamento, como um disco, por exemplo, além de poder com-partilhá-los com outros processos. A forma pela qual o sistema operacional estrutura estas informações é através da implementação de arquivos.

Quando um processo cria um arquivo, ele dá um nome a esse arquivo. Quando o processo termi-na, o arquivo continua disponível e outros processos podem acessá-lo simplesmente buscando seu nome.

133Tema 4 | Segurança de sistemas operacionais

Nomes de Arquivo

As regras para se nomear um arquivo variam entre sistemas operacionais. O MS-DOS, por exem-plo, permitia cadeias de caracteres de 1 até 8 carac-teres alfa-numéricos como nomes válidos de arquivos. Caracteres especiais como # $ % & @ ! não eram permitidos.

Hoje a maioria dos sistemas operacionais aceita nomes com até 255 caracteres e alguns ca-racteres especiais. É importante perceber que al-guns sistemas operacionais distinguem letras maiúsculas de letras minúsculas (case sensistive). No Linux, por exemplo, Teste, teste e TESTE, poderiam ser três nomes de arquivos diferentes. Já no Windows corresponderiam ao mesmo arquivo.

Experimente ver qual o maior nome consegue dar a um arquivo.

Alguns sistemas operacionais suportam nomes de arquivos divididos em duas partes separadas por um ponto. Os caracteres após o ponto correspondem à extensão do arquivo, e normalmente é um indicador de algo sobre o arquivo. Por exemplo, no nome de arquivo teste.txt, a extensão .txt nos diz que corresponde a um arquivo de texto.

No MS-DOS, a extensão de arquivos era limitada a 3 caracteres. Nos sistemas operacionais baseados no UNIX16, o tamanho da extensão de arquivos, se houver, fica a critério do usuário.

Por outro lado, sistemas operacionais como o Windows conhece as extensões a atribui significado a elas. Quando um usuário clica duas vezes em um nome de arquivo, o programa atribuído à sua extensão é executado tendo o arquivo como um parâmetro.

16 No Unix as extensões de arquivos são apenas convenções, já que não são impostas pelo sistema operacional.


Atributos de Arquivos

As informações de controle que cada arquivo possui são chamadas de atributos, que variam entre os sistemas operacionais, mas há alguns que estão presentes em quase todos os sistemas, como tamanho do arquivo, data de criação e outros.

Vá até seu gerenciador de arquivos e peça para visualizar todos os detalhes do arquivo. Você, então, verá seus atributos.

Existem atributos que não podem ser modifica-dos, como sua organização e a data/hora do momen-to de sua criação, e atributos que são alterados pelo próprio sistema operacional, como data/hora da última alteração, ou pelo usuário, como senhas de acesso.

Figura 48 - Atributos de Arquivos


Estrutura de Arquivos

Existem diversas maneiras dos arquivos serem estruturados, uma delas é através de uma sequência desestruturada de bytes, em que o sistema operacional não sabe o que o arquivo contém. Tudo o que ele vê são bytes. Sistemas como o Windows e Unix utilizam essa estratégia.


Figura 49 - Sequência de Bytes

Fonte - TANENBAUM, Andrew S. Sistemas operacionais modernos. 2. ed. Rio deJaneiro: Prentice Hall Brasil, 2007, p.288.

Outro modelo de estrutura de arquivos é uma sequência de registros de tamanho fixo, cada um com alguma estrutura interna. Neste modelo, a operação de leitura retorna um registro e a operação de escrita sobrepõe ou anexa um registro.

Figura 50 - Sequência de registros



O terceiro modelo mais comum de estrutura de arquivo é constituído de uma árvore de regis-tros, cada um contendo um campo-chave em uma posição fixa no registro. Essa árvore é ordenada pelo campo-chave para que se busque mais rapida-mente por uma chave específica.

Figura 51 - Árvore de registros


Tipos de Arquivos

Normalmente muitos sistemas operacionais suportam vários tipos de arquivos. Os arquivos re-gulares, em geral, são arquivos ASCII ou arquivos binários. Arquivos ASCII são constituídos de linhas de texto e arquivos binários têm, em geral, alguma estrutura conhecida pelos programas que o utilizam.

Já os arquivos especiais de caracteres estão relacionados à entrada/saída e são usados para modelar os dispositivos de entrada/saída (terminais, impressoras e redes).

Os arquivos especiais de bloco, por sua vez, são usados para modelar discos, enquanto que os diretórios são arquivos do sistema que mantêm a estrutura do sistema de arquivos.


Operações com arquivos

A função dos arquivos é armazenar informações e permitir que elas sejam recuperadas depois. O sistema operacional fornece chamadas ao sistema para criar, ler, escrever, excluir, reposicionar e truncar arquivos.

Criar um arquivo – acontece em duas etapas. Primeiro, deve haver espaço no sistema de arqui-vos para que o arquivo seja criado. Segundo, uma entrada do arquivo deve ser feita no diretório.

Escrever em um arquivo – é feita uma cha-mada ao sistema onde é especificado o nome do arquivo e as informações a serem escritas nele.

Ler um arquivo – é feita uma chamada ao sistema que especifique o nome do arquivo e a po-sição na memória onde o próximo bloco do arquivo deverá ser colocado.

Reposicionar dentro do arquivo – O diretório é pesquisado buscando a entrada apropriada e a posição do arquivo atual é ajustada para um deter-minado valor.

Excluir um arquivo – é feita uma chamada de sis-tema para remover o arquivo e liberar o espaço que ele ocupa. É apagada também sua entrada no diretório.

Truncar o arquivo – permite que todos os atributos permaneçam inalterados (exceto pelo ta-manho do arquivo).

Diretórios

A forma de o sistema operacional organizar logicamente os arquivos armazenados em disco é através de uma estrutura de diretórios. Ela possui entradas associadas aos arquivos onde cada uma delas armazena informações como localização física, nome e demais atributos.


No momento em que um arquivo é aberto, o sistema operacional procura sua entrada de diretó-rios, armazenando as informações sobre atributos e localização do arquivo em uma tabela mantida na memória principal.

Em sua maioria, os diretórios são organizados em uma estrutura de árvore em que cada usuário pode criar diversos níveis de diretórios chamado subdiretórios. Cada diretório pode conter arquivos ou outros diretórios.

Figura 52 - Estrutura de diretórios em árvore



Este modelo de múltiplos níveis permite que os arquivos sejam logicamente melhor organizados. O nú-mero de níveis de uma estrutura em árvore depende do sistema de arquivos de cada sistema operacional.

Faça um teste para saber qual o limite de subdiretórios em seu sistema.

Implementação de Arquivos

Uma das questões mais importantes ao imple-mentar o armazenamento de arquivos é monitorar quais blocos de disco acompanham quais arquivos. Vejamos algumas técnicas de alocação de arquivos:

Alocação Contígua

O modelo de alocação contígua consiste em armazenar um arquivo em blocos sequencialmente dispostos no disco. É simples de implementar, pois monitorar a localização dos blocos reduz-se a guar-dar seu endereço. Além disso, possui um excelente desempenho, pois o arquivo inteiro pode ser lido do disco em uma única operação.

Figura 53 - Alocação contígua do espaço em disco para 7 arquivos


Contudo, algumas desvantagens podem ser per-cebidas neste modelo. Primeiro não pode ser aplicável a não ser que o tamanho máximo do arquivo seja conhecido no momento em que o arquivo é criado.


Segundo porque este modelo gera uma gran-de fragmentação dos arquivos, resultante dessa política de alocação.

Alocação com Lista Encadeada

Na técnica da alocação com lista encadeada, um arquivo pode ser organizado como um conjunto de blocos ligados logicamente no disco, indepen-dente de sua localização física. Cada bloco deve possuir um ponteiro para o bloco seguinte do arquivo e assim por diante.

Figura 54 - Alocação encadeada.


Apesar de não apresentar as desvantagens da alocação contígua, a fragmentação resultante deste modelo ocasiona um aumento no tempo de acesso aos arquivos (excessivo tempo de seek).

Se nunca fez uma desfragmentação de disco, agora sabe sua importância! Reflita sobre isso e divulgue suas conclusões no AVA para discussão.


Alocação com Lista Encadeada Usando Índice

O princípio do modelo da alocação com lista encadeada usando índice é manter os ponteiros de todos os blocos do arquivo em uma única estrutura chamada bloco de índice.

Figura 55 - Alocação Indexada


Com esta organização, o bloco inteiro está disponível para dados e o acesso aleatório é muito mais fácil. E além de permitir o acesso direto aos blocos do arquivo, não utiliza informações de controle nos blocos de dados, como na alocação encadeada.

I-Node (index-node)

Este modelo consiste em associar a cada ar-quivo uma estrutura de dados chamada i-node, que relaciona os atributos e os endereços em disco dos blocos de arquivo.


Uma grande vantagem deste modelo em relação ao anterior é que o i-node só precisa estar na memória quando o arquivo correspondente estiver aberto, enquanto no modelo anterior, toda a tabela de índice deve estar na memória todo o tempo.

Figura 56 - Exemplo de i-node




Para saber mais sobre Sistemas de Arquivo, leia o Capítulo 6 (p. 284-336) do livro de:

TANENBAUM, Andrew S. Sistemas operacionais mo-dernos. 2. ed. Rio deJaneiro: Prentice Hall Brasil, 2007.

Tanembaun apresenta em seu livro detalhes de im-plementação e gerenciamento de sistemas de ar-quivo em diversos sistemas operacionais.

Para saber mais sobre Sistemas de Arquivo, leia o Capítulo 11 (p. 212-228) do livro de:


Através de ilustrações que auxiliam na compreen-são dos tipos de processos, os autores Francis e Luiz Paulo apresentam o assunto de forma clara e com exemplos de situações vividas por usuários.

PARA REFLETIR

Ao instalar um sistema operacional como o Linux ou Windows pode-se escolher qual sistema de arquivo deseja utilizar. Pense a respeito de como escolher o sistema de arquivo ideal para seu sistema.


4.2 Princípios de Segurança de Sistemas Operacionais

Um fator de imensa importância que deve ser levado em consideração nos projetos de sistemas operacionais é a questão da segurança17 que está ligada diretamente ao gerenciamento dos sistemas de arquivos, pois é ali que estão as informações valiosas de seus usuários.

Muitas questões devem ser levadas em con-sideração na segurança de um sistema como:

A confidencialidade dos dados, que significa manter em sigilo dados secretos, e aí entra também a privacidade do usuário contra o mau uso da infor-mação sobre eles;

A integridade dos dados, em que usuários não autorizados não devem ser capazes de modificar qualquer dado sem a permissão do proprietário;

A disponibilidade do sistema, em que ninguém pode interferir no sistema para deixá-lo inoperante.

Invasores

Na categoria de invasores de sistemas com-putacionais, temos aqueles que simplesmente de-sejam ler os arquivos não autorizados e outros que querem alterar os dados alheios.

Um vírus é basicamente um pequeno progra-ma que se replica com a finalidade de causar algum dano, pode ser considerado um invasor, ou uma ferramenta de quem o escreveu.

Quantos tipos de vírus você conhece?

Um worm (verme) é um processo que usa o mecanismo de propagação para acabar com o

17 Em 1985 foi publicado um docu-mento formalmente conhecido como o padrão DoD 5200.28 do Departamento de Defesa dos Estados Unidos, mais popu-larmente conhecido como Livro Laranja (Orange Book), por causa da cor de sua capa.


desempenho do sistema. Ele distribui cópias de si mesmo esgotando os recursos do sistema, bloquean-do até seu uso pelos demais processos.

Enquanto os vermes são estruturados como programas completos e independentes, um vírus é um fragmento de código embutido em um programa legítimo.

Quantas formas de propagação você conhece?

Já ouviu falar do cavalo de troia? Ele é um vírus ou um verme? Reflita sobre isso e divulgue suas conclusões no AVA para discussão.

A Segurança Java

Quando pensamos em invasão de computa-dores, imediatamente imaginamos a internet como seu principal meio. Assim, é fácil entender por que a segurança é um recurso importante da linguagem Java, já que os programas podem operar em um ambiente distribuído (como a internet).

O melhor exemplo desses programas é o uso de applets, que consiste em um programa Java que é descarregado de um servidor Web e que executa uma página web.

Se o JVM (Java Virtual Machine – Máquina vir-tual do Java) no navegador não fornecer recursos de segurança suficientes, um applet poderia executar aplicativos maliciosos no computador.

Vale a pena desativar o recurso Java de seu navegador para garantir sua segurança? Pense a respeito e divulgue suas conclusões no AVA para discussão.


Perda de Dados

Além de todos os problemas de ameaças causados por invasores, dados podem ser perdi-dos por diversos fatores como: perda acidental (incêndios, enchentes, quedas e outros), proble-mas de hardware ou software (defeitos na placa mãe, CPU, erros de programas e outros) e erros humanos (entrada incorreta de dados, execução errada do programa e outros).

A melhor solução para evitar dores de ca-beça quando o assunto é perda de dados é man-ter sempre uma cópia de segurança (backup) atu-alizada, de preferência fisicamente distante dos dados originais.

Criptografi a

O objetivo da criptografia é esconder o signi-ficado de uma informação (um processo conhecido como encriptação). Através dele as informações são codificadas para preservar seu conteúdo original, e somente quem possuir a chave dessa codificação poderá conhecer seu significado.

A criptografia pode ser dividida em dois ramos conhecidos como transposição e substituição. Na transposição, as letras da mensagem são simplesmente rearranjadas, gerando um anagrama.

Figura 57 - Exemplo de Transposição

Fonte - SINGH, Simon. O livro dos códigos – a ciência do sigilo – do antigo Egito à criptografi a quântica. 7. ed. Rio de Janeiro: Record, 2008, p. 24.


Na substituição cada caractere de uma mensagem é substituído por outro caractere. Uma das técnicas muito utilizada era o emparelhamento ao acaso das letras do alfabeto, substituindo cada letra na mensagem original por seu par.

Figura 58 - Cifra de Deslocamento de César

Fonte - SINGH, Simon. O livro dos códigos – a ciência do sigilo – do antigo Egito à criptografia

quântica. 7. ed. Rio de Janeiro: Record, 2008, p. 27.

Figura 59 - Criptografi a Simétrica

Fonte-http://penseresponda.fi les.wordpress.com/2009/04/imagem11.jpg?w=450&h=161. Acesso em: 17 de dez. de 2010.

Criptografi a com Chave Simétrica

O ciframento de uma mensagem baseia-se em dois componentes: um algoritmo e uma chave. Um algoritmo é uma transformação matemática, ele converte uma mensagem clara em uma mensagem cifrada e vice-versa.


Quando temos a mesma chave para o cifra-mento e o deciframento, o processo da criptografia é conhecido como Simétrica.

Criptografi a com Chave Assimétrica

Também conhecida como criptografia de chave pública, é uma estratégia de criptografia que combina um par de chaves, uma chave privada e uma chave pública.

A chave pública pode ser distribuída livremente para qualquer correspondente até mesmo por e-mail ou outras formas, já a chave privada deve ser conhecida apenas pelo seu dono.

Em um algoritmo de criptografia assimétrica, um código cifrado com a chave pública pode somente ser decifrado pela sua correspondente chave privada.

Figura 60 - Criptografi a Assimétrica

Fonte - http://penseresponda.fi les.wordpress.com/2009/04/imagem2.jpg?w=450&h=153. Acesso em: 17 de dez. de 2010

A grande vantagem deste sistema é permitir que qualquer um possa enviar uma mensagem secreta, apenas utilizando a chave pública de quem irá recebê-la. Como a chave pública está amplamente disponível, não há necessidade do envio de chaves como é feito no modelo simétrico.

Uma chave de dois dígitos permite 100 com-binações. Uma chave com seis dígitos, 1 milhão de combinações. Imagine uma chave de 256 bits.


Assinatura Digital

Uma assinatura digital torna possível assinar mensagens eletrônicas e qualquer outro documen-to digital de modo a garantir sua autenticidade e evitar seu repúdio por quem a enviou.

Como foi visto, uma chave pública é usada para cifrar uma mensagem que só pode ser deci-frada por uma única chave privada. Mas o processo pode ser invertido, de modo que a chave privada seja usada para cifrar e a chave pública para decifrar.

Sendo feito desta forma, não garantiria ne-nhuma segurança à mensagem, já que qualquer chave pública poderia decifrar a mensagem cifrada pela chave privada, mas garantiria sua autenticida-de, pois se puder decifrar a mensagem usando uma chave pública, ela só poderia ter sido cifrada com a chave privada correspondente.

O valor resultante, chamado de bloco de as-sinatura, é anexado ao documento e enviado ao receptor. Para usar esse esquema, o receptor deve conhecer a chave pública do emissor.

Autenticação de Usuário

Normalmente para se ter acesso ao sistema operacional o usuário deve passar por um proces-so de autenticação, cuja maneira mais amplamente utilizada atualmente é pedir que o usuário digite um nome e uma senha.

A implementação mais simples de um siste-ma de autenticação de usuário é manter uma lista central de pares (nome de entrada, senha). O nome de entrada digitado é localizado na lista e a senha digitada comparada. Se coincidirem, o acesso será permitido, do contrário será rejeitado.


Ataques Genéricos de Segurança

A partir do conhecimento do funcionamento, rotinas e estruturas do sistema operacional é possí-vel identificar algumas vulnerabilidades do sistema. Veja algumas estratégias utilizadas em ataque de sistemas:

• Requisitar páginas de memória e espaço em disco para leitura. Muitos sistemas não apagam nada antes de alocar esses espaços novamente e eles podem conter informações importantes escritas pelos antigos proprietários e essas informações permanecem lá até seu espaço ocupado ser utilizado novamente.

• Tentar chamadas ao sistema inválidas ou chamadas ao sistema válidas com parâ-metros inválidos, ou até mesmo chama-das ao sistema válidas com parâmetros válidos, mas fora dos limites, como no-mes de arquivos com milhares de carac-teres. Muitos sistemas podem ser confun-didos com facilidade.

• Iniciar o acesso ao sistema e, então, no meio desse processo, pressionar Delete ou Break. Em alguns sistemas é possível interromper o processo de verificação de senha e o acesso concedido.

• Tentar modificar estruturas do sistema operacional que ficam no espaço do usuário (se houver). Em alguns sistemas, para abrir um arquivo o programa constrói uma grande estrutura de dados contendo


o nome do arquivo e muitos outros pa-râmetros e passa para o sistema. Alterar esses campos pode arruinar a segurança.

Mecanismos de Proteção

Em alguns sistemas, a proteção é implemen-tada por um programa chamado monitor de referên-cia. Cada vez que se tenta um acesso a um recurso potencialmente protegido, o sistema pede primeiro ao monitor de referência para verificar sua validade.

Domínios de Proteção

Uma forma de entender melhor como é feita uma proteção de domínio é analisarmos como os sistemas operacionais baseados no UNIX (como o Linux) tratam os privilégios de seus processos.

No UNIX, um processo é definido pelo seu UID (Id do usuário) e GID (Id do grupo). Dada qual-quer combinação entre eles é possível criar uma lista completa de todos os objetos representados pelos arquivos especiais que podem ser acessados e seus privilégios18 (leitura, escrita ou execução).

18 O UNIX utiliza 3 bits para defi nir os argumentos de permissão de arquivo rwx. r=read (leitura), w=write (escrita) e x=execute (execução).

Figura 61 - Exemplo de Listagem de diretório no Unix

Fonte - SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas operacionais com java - conceitos e aplicações.Tradução da 6. ed. Rio de Janeiro: Campus, 2005, p. 264.


Lista de Controle de Acesso (ACL)

A lista de controle de acesso (ACL – Access Control List) consiste em uma lista associada a cada arquivo, onde são definidos quais os usuários e os tipos de acesso permitidos. Assim, quando um usuário tenta acessar um arquivo, o sistema operacional verifica se a lista de controle autoriza a sua operação.

A maioria dos sistemas operacionais suporta o conceito de grupo, onde cada processo tem um identificador do usuário (UID) e um identificador de grupo (GID19). Assim, as entradas da ACL podem receber as duas identificações, ficando mais fácil agrupar permissões a um grupo de usuários específicos.


Para saber mais sobre Princípios de Segurança de Sistemas Operacionais leia o Capítulo 9 (p. 439-499) do livro de:

TANENBAUM, Andrew S. Sistemas operacionais mo-dernos. 2. ed. Rio deJaneiro: Prentice Hall Brasil, 2007.

Tanenbaum apresenta os principais tipos de quebra de segurança existentes, dando exemplos em siste-mas operacionais específicos e mostrando algumas soluções para evitá-las.

Para saber mais sobre Princípios de Segurança de Sistemas Operacionais leia o Capítulo 19 (p. 418-434) do livro de:

19 Conforme visto acima.


SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas operacionais com java - conceitos e aplica-ções.Tradução da 6. ed. Rio de Janeiro: Campus, 2005.

Em Sistemas Operacionais com Java, a segurança é apresentada com suas possibilidades aplicáveis apresentando exemplos em sistema operacional específico (Windows) e na linguagem Java.

PARA REFLETIR

Mesmo com as mais sofisticadas implementações de segurança adotadas, de nada adiantaria se o usuário deixasse sua senha escrita sobre a mesa; se a sala do servidor for de fácil acesso a qualquer um. Acredita, então, que é possível um responsável pela segurança de um sistema desconsiderar o elemento humano? Pense a respeito.


4.3 Cases Windows

Resumo Histórico

Em 1981 a Microsoft lançou o MS-DOS (Micro-soft – Disk Operating System) como seu primeiro sistema operacional para a linha de computado-res pessoais IBM-PC. Era um sistema operacional de 16 bits, monoprogramável, monousuário e sem interface gráfica (sua interface com o usuário era através de linha de comando).

Em 1985, a Microsoft lançou a primeira ver-são do MS-Windows, com uma interface gráfica para o usuário, mas mantendo o MS-DOS como sistema operacional. As versões posteriores do MS-Windows, como o Windows 3.1/3.11, 95/98 e Me, apesar de diversas inovações e melhorias, sempre estiveram associadas ao velho MS-DOS.

Sabia que até a versão Windows Me, mesmo que surgisse uma janela para a autenticação do usuário, bastava pressionar o botão cancelar para usar o sistema?

Na década de 90, mais precisamente em 1993, a Microsoft lançou o Windows NT, um sistema operacional completamente reescrito sem qualquer relação com a arquitetura do MS-DOS, mas ofere-cendo compatibilidade parcial com as aplicações herdadas. Tratava-se de um sistema operacional de 32 bits, com multitarefa preemptiva, multithread, memória virtual e suporte a múltiplos processado-res simétricos.

O Windows NT acompanhou a evolução da família MS-DOS – Windows e com isso passaram a existir duas linhas de sistemas operacionais da Microsoft com arquiteturas completamente distin-tas, normalmente uma para uso corporativo e outra para usuários domésticos.


Nesse contexto destacamos o Windows 2000, uma evolução da versão 4 do Windows NT que trou-xe como maior novidade a substituição do conceito de domínio, existente no NT, pelo Active Directory, que funciona como um serviço de diretórios.

Em 2001, a Microsoft integrou as duas linhas de sistemas operacionais lançando o Windows XP, introduzindo uma nova interface gráfica, mas com a mesma arquitetura do Windows 2000.

Figura 62 - Evolução do Windows (até o XP)


Dois anos depois, em 2003, foi lançado o Windows Server 2003, como um sucessor do Win-dows 2000, tendo o mesmo núcleo do Windows XP, mas com algumas funções desabilitadas, o que per-mitia um funcionamento mais estável do sistema.


Essa versão do Windows possui ferramentas de administração funcionais como o Gerenciador de Recursos do Servidor de Arquivos, que é um con-junto de ferramentas que permite aos administra-dores entender, controlar e gerenciar a quantidade e os tipos de dados armazenados nos servidores; além do DFS (Sistemas de Arquivos Distribuídos) que contém as novas tecnologias modernas de re-plicação, gerenciamento e compactação para asse-gurar o uso eficiente da largura de banda.

O Windows 2003 possui 4 versões: Web Edi-tion, Standard Edition, Enterprise Edition e Data-center Edition, cada uma com a finalidade de aten-der uma demanda específica do mercado.

Em 2006, foi lançado o Windows Vista com centenas de novas funções e uma nova interface gráfica, mas sendo um sistema operacional pesado, composto de mais de 100 milhões de linhas de có-digo e que exige bastante do hardware da máquina.

O Vista trouxe modificações significativas na parte gráfica. Com a ferramenta Aero, deixa o desktop mais agradável aos olhos com as janelas transparentes que trazem uma movimentação mais suave; e com o Flip 3D, é possível apresentar todas as janelas abertas com um efeito cascata 3D. Além disso, traz o WDDM (Windows Display Drivers Mo-del) um modelo de driver básico para suportar as mudanças na interface do Windows Vista. Baseia-se em processamento paralelo na GPU (Graphics Pro-cessing Unit – Unidade de Processamento Gráfico).

Destacamos também que com o User Mode Driver (Modo de driver de usuário) as instalações e utilizações de drivers são feitas em modo usuário, especialmente dedicado a periféricos e memória USB.

Em 2008 a Microsoft lançou, em substituição ao Windows Server 2003, o Windows Server 2008, projetado para fornecer recursos para outros sistemas


em uma rede. A versão Standard Edition suporta 2-way e 4-way SMP (multiprocessamento simétrico) e até 4 Gb de memória RAM em sistemas de 32 bits e 32 Gb em sistemas de 64 bits. Suas versões disponíveis são: Web Edition, Datacenter Edition, Enterprise Edition e o Windows Server 2008 R2.

O Windows Server 2008 R2 foi construído com base no Windows Server 2008 e trata-se de uma nova versão do sistema operacional diferen-temente do Windows Server 2003 R2 que foi uma atualização. O R2 é o primeiro a ser lançado apenas na versão de 64 bits.

Um dos recursos interessantes nesta versão é o “server-core”, uma opção de instalação do siste-ma operacional que possui algo em torno de apenas 10% do seu código em GUI (Graphic User Interface – Interface Gráfica do Usuário), o restante fica todo operativo em linha de comando. Com o server core instalado com os binários básicos necessários para o funcionamento de um servidor corporativo, menos portas virtuais são abertas tornando o software mais seguro, compacto e com maior throughput.

O R2 traz ainda a nova tecnologia Hyper V que irá competir com a VMware na virtualização de máquinas.

Finalmente, em 2009, a Microsoft lançou o Windows 7, a versão mais recente de seu sistema operacional. Apesar das grandes semelhanças na interface com o Windows Vista, muitas mudanças no código ocorreram que alteraram imensamente a forma como o programa se comporta, melhorando o desempenho geral da máquina.

O Windows 7 atende à necessidade cada vez maior de soluções de controle de aplicativos com a introdução do AppLocker, um mecanismo simples e flexível que permite aos administradores especificar exatamente o que pode ser executado em seu ambiente de trabalho.


O Windows 7 vem nas versões Starter, Home Basic, Home Premium, Professional e Ultimate.

No Windows 7 destacamos ainda a Cripto-grafia de Unidade de Disco BitLocker que ajuda a evitar que um intruso possa inicializar um outro sistema operacional ou utilizar uma ferramenta de acesso ilegal para romper as proteções de sistemas e arquivos do Windows 7; e o DirectAcces, com o qual a produtividade dos usuários remotos é incre-mentada, permitindo que eles acessem, de forma contínua e segura, a rede corporativa sempre que tiverem uma conexão com a internet, sem necessi-tar de uma conexão VPN (Virtual Private Network – rede virtual privada).

Apesar de o Windows 7 ser uma versão pos-terior ao Windows Vista, ele se comporta com um desempenho superior em um mesmo hardware. Pense sobre isso e divulgue suas conclusões no AVA para discussão.

O Windows 2000

Vamos utilizar a versão 2000 do Windows para analisarmos seus modelos, componentes e estrutura interna por ter sido ainda uma versão voltada para o mundo corporativo, mas que foi utilizada para compor a versão XP.

O Windows 2000 é um sistema operacional multiprogramável de 32 bits, que suporta escalona-mento preemptivo, multithread, multiusário, multi-processamento simétrico (SMP) e memória virtual. O sistema é estruturado combinando o modelo de camadas e cliente-servidor.


Figura 63 - Versões do Windows 2000


Estrutura do sistema operacional

O Windows 2000 é composto de duas partes, o próprio sistema operacional (que executa no modo kernel) e os subsistemas do ambiente (que executa no modo usuário). O kernel é um núcleo tradicional e os subsistemas não são usuais, pois são processos isolados que ajudam os programas do usuário a realizar certas funções do sistema.

Figura 64 - A estrutura do Windows 2000 (bastante simplifi cada). A área sombreada é o executivo. As caixas indicadas por D são os drivers de dispositivos.



A Camada de Abstração de Hardware

Um dos objetivos do Windows 2000 (e do Windows NT) era tornar o sistema operacional por-tátil em várias plataformas, assim a Microsoft se empenhou em ocultar grande parte das dependên-cias de máquina em uma fina camada chamada HAL (hardware abstraction layer - camada de abstração de hardware).

Conhece o filme “2001 uma Odisseia no Espaço”? Você lembra o nome do computador no filme?

A função da HAL é apresentar a uma parte do sistema operacional dispositivos abstratos de hardware desprovidos de especificidades e idios-sincrasias das quais o hardware real está repleto.

A Camada do Núcleo

Acima da camada de abstração de hardwa-re encontram-se uma camada que contém o que a Microsoft chama de núcleo e também os drivers de dispositivos.

O propósito do núcleo é tornar o sistema operacional completamente independente do har-dware e, como consequência, altamente portátil.

O Executivo

Acima do núcleo e dos drivers de dispositivo está a parte superior do sistema operacional, cha-mada executivo. O executivo é escrito em C, é in-dependente da arquitetura e pode ser transporta-do para novas máquinas com relativamente pouco esforço. Nele estão todos os conjuntos de geren-ciadores do sistema (Gerenciadores de objeto, de entrada/saída, de processos, de memória, de segu-rança e de cache).


Subsistemas do Ambiente

O Windows 2000 suporta três diferentes APIs: win32, POSIX e OS/2. Cada uma dessas interfaces tem uma lista pública de chamadas de biblioteca que pro-gramadores podem usar.

O trabalho das DLL (Dynamic Link Libraries – bibliotecas de ligações dinâmicas) e dos subsistemas do ambiente é implementar a funcionalidade da inter-face pública, ocultando dos programas de aplicação, a verdadeira interface da chamada ao sistema.

Gerência do Processador

O Windows 2000 suporta dois tipos de polí-tica de escalonamento: circular (Round Robin) com prioridades e escalonamento por prioridades.

O código de escalonamento é implementado no kernel do sistema. Não existe uma rotina única para o escalonador, pois seu código está espalhado pelo kernel. Essas rotinas são chamadas de kernel dispatcher.

Processos e threads

No Windows 2000 um processo é criado quando um outro processo faz a chamada Create-Process da win32. Essa chamada solicita um pro-cedimento, no modo usuário, no núcleo32.dll, que cria um processo em várias etapas realizando múl-tiplas chamadas ao sistema e outras tarefas.

Sistema de Arquivos

O Windows 2000 suporta três tipos de sis-temas de arquivos: FAT, FAT32 e NTFS. Este último foi projetado especialmente para o Windows NT e posteriormente atualizado para o Windows 2000 oferecendo alto grau de segurança e desempenho.


Cada sistema determina como os arquivos e diretórios são organizados, o formato dos nomes dos arquivos, desempenho e segurança de acesso aos dados.

Você pode converter o sistema de arquivos de um disco de FAT32 para NTFS mesmo depois do Windows instalado. Mas não pode fazer o inverso. Verifique qual é o seu sistema de arquivo.

O Registro

O Windows precisa controlar uma grande quantidade de informação sobre o software, o har-dware e os usuários. Desde o Windows 95, quase toda informação necessária para iniciar, configurar o sistema e adaptá-lo ao usuário foi reunida em um banco de dados central chamado registro.

Ele é parecido com um pequeno sistema de arquivos, com uma coleção de diretórios, cada um contendo subdiretórios ou entradas.

Você pode acessar o seu registro executando o comando regedit. Mas, cuidado, qualquer altera-ção inadvertida poderá interromper o funcionamento normal de seu sistema.


Para saber mais sobre Cases Windows, leia o Capítulo 11 (p. 571-637) do livro de:

TANENBAUM, Andrew S. Sistemas operacionais modernos. 2. ed. Rio de Janeiro: Prentice Hall Brasil, 2007.


Tanembaun apresenta em seu livro características particulares com códigos e implementações no am-biente do sistema operacional Windows.

Para saber mais sobre Cases Windows, leia a Parte 4, Capítulo 14 (p. 267-285) do livro de:MACHADO, Francis B.; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 4. ed. Rio de Janeiro: LTC, 2007.

Neste livro pode ser encontrada a explicação deta-lhada de cada etapa da gerência feita na camada do executivo.

PARA REFLETIR

Com tantas versões já lançadas do Windows, acre-dita que valha a pena utilizar sempre a versão mais recente do sistema operacional? Reflita sobre isso.


4.4 Cases Linux

Resumo Histórico

O Linux é um sistema operacional que teve seu desenvolvimento iniciado por um estudante finlandês chamado Linus Torvalds, que realizou um processo pessoal de aprimoramento do Kernel do Minix, um sistema operacional do tipo Unix escrito por Andrew Tannenbaum, chamando esta vertente de Linux como abreviação de Linus´s Minix.

Linus possuía um PC 386 e o MS-DOS não sa-tisfazia suas pretensões como usuário. Essa foi sua motivação.

O desenvolvimento do Kernel Linux contou com a colaboração de diversos programadores que auxilia-ram no desenvolvimento do seu núcleo. Sua primeira versão oficial foi lançada em outubro de 1991 e no início de 1992 se integrou ao projeto GNU20 com o ob-jetivo de produzir um sistema operacional completo.

20 Projeto criado em 1984 por Richard Stallman e organizado pela Free Software Foun-dation, corporação que busca promover softwares livres e a licença GPL (General Public License).

Figura 65 - Evolução do UNIX



Só o kernel Linux não era suficiente para se ter um sistema funcional, portanto, empresas, orga-nizações e grupos de pessoas decidiram distribuir o Linux juntamente com outros programas essenciais (editores de texto, planilhas, banco de dados, ambiente de programação e outros).

Uma distribuição, portanto, é um sistema operacional com o kernel Linux e outros softwares de aplicação, formando um conjunto mantido por organizações comerciais, como a Red Hat, Ubuntu, SUSE e Mandriva, bem como por projetos comuni-tários como Debian e Gentoo, que montam e tes-tam seus conjuntos de software antes de disponi-bilizá-los ao público.

Já usou alguma distribuição Linux? Procure uma distribuição Live CD e faça um teste em seu micro.

Como o Linux e normalmente a maior parte dos softwares embutidos em distribuições são li-vres, qualquer pessoa ou organização pode criar e disponibilizar, comercialmente ou não, a sua pró-pria distribuição.

UNIX – Linux

Como já foi visto, o Linux é um sistema ope-racional tipo UNIX que durante seu processo de de-senvolvimento diversos programas e funcionalida-de do sistema UNIX foram implementados no Linux.

O sistema segue o padrão POSIX que é o mesmo usado por sistemas UNIX, assim, chamadas ao sistema, programas, bibliotecas, algoritmos e estruturas internas de dados são muitos similares às do UNIX.

O Linux é um sistema multiprogramável, mul-tiusuário, que suporta múltipos processadores e implementa memória virtual.


Interpretador de Comandos

O Linux pode utilizar diversas interfaces grá-ficas, as mais conhecidas são o KDE (K Desktop En-vironment) e o GNOME (GNU Network Object Model Environment). No entanto, os programadores e usu-ários mais experientes ainda preferem uma interfa-ce em linha de comando chamada de interpretador de comando ou shell. Este possui uma performance muito mais rápida, mais poderosa e facilmente ex-tensível. Existem diversos shells para Linux, os mais conhecidos são o sh, bash, ksh, entre outros.

Estrutura do Sistema Operacional

A maior parte do núcleo do Linux é escrita em Linguagem C e o restante em assembly, o que confere ao sistema uma grande portabilidade para diferentes plataformas de hardware.

Figura 66 - Componentes do sistema Linux

Fonte - SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas operacionais com java - conceitos e aplicações.Tradução da 6. ed. Rio de Janeiro: Campus, 2005, p. 478.

O sistema Linux é composto por três blocos de código principais, alinhados com as implemen-tações mais tradicionais do UNIX.

O kernel é responsável pela manutenção de todas as abstrações importantes do sistema opera-cional, incluindo elementos como a memória virtual e os processos.


As bibliotecas do sistema definem um con-junto padrão de funções por meio das quais as aplicações podem interagir com o kernel, e que implementam grande parte da funcionalidade do sistema que não necessita dos privilégios totais do código do kernel.

Os utilitários do sistema são aplicativos que executam tarefas de gerência à parte e especializa-das. Alguns são executados uma única vez, outros (os daemons) podem manter-se em execução per-manente em tarefas como: responder a conexões de rede, aceitar pedidos de login ou atualizar ar-quivos de log.

Módulos do Kernel

O kernel Linux é capaz de carregar e descar-regar seções arbitrárias de código de kernel sob demanda. Esses módulos são executados em modo kernel privilegiado, assim, têm acesso total a todos os recursos da máquina.

Teoricamente, não existem restrições ao que um módulo kernel pode fazer. Normalmente, um mó-dulo pode implementar um driver de dispositivo, um sistema de arquivos ou um protocolo de rede.

O fato de o código fonte do Linux ser livre, faz com que seja bastante conveniente ter módulos de kernel. Reflita sobre isso e divulgue suas conclu-sões no AVA para discussão.

Sistemas de Arquivos

O Linux manteve o modelo de sistemas de arquivo do UNIX, onde um arquivo não necessaria-mente tem de ser um objeto armazenado em disco ou buscado em um servidor remoto. Ele pode ser qualquer entidade capaz de tratar a entrada ou sa-ída de um fluxo de dados.


O kernel Linux lida com todos esses diversos tipos de arquivos através de uma camada de sof-tware, o sistema de arquivos virtual (VFS – Virtual File System), que oculta os detalhes da implemen-tação de qualquer tipo de arquivo.

Ao contrário do Windows, o Linux suporta uma grande diversidade de sistemas de arquivo, atualmente o mais utilizado é o ext4 (sucessor do ext3 o mais utilizado até então).

Uma curiosidade, o sistema ext4 suporta volumes de até 1exabyte21! Consegue imaginar?

Processos e Threads

Processos no Linux/Unix são chamados de daemons e são responsáveis por tarefas adminis-trativas no sistema. São criados automaticamente durante a inicialização do sistema.

É possível criar processos foreground e back-ground. No primeiro caso existe uma comunicação direta do usuário com o processo durante sua exe-cução. Já um processo background22 não pode ter interação com o usuário.

O kernel Linux lida de modo simples com a di-ferença entre processos e threads: utiliza exatamente a mesma representação interna para ambos. Um thre-ad é apenas um processo que, por acaso, compartilha o mesmo espaço de endereçamento de seu pai.

Comunicação entre Processos

O mecanismo padrão do Linux para informar um processo sobre a ocorrência de um evento é um sinal. Ele pode ser enviado a partir de qual-quer processo para qualquer outro (com algumas restrições).

21 Para quem não consegue imaginar: 1024 mega = 1 giga. 1024 giga = 1 tera. 1024 tera = 1 peta. 1024 peta = 1 exa.

22 Conforme já visto no item 2.2


Existe apenas um número limitado de sinais disponíveis e eles não podem carregar informações: só o fato de que ocorreu um sinal é disponibilizado para um processo. Os sinais não precisam ser gera-dos necessariamente por outro processo, o kernel também gera sinais intermitentes.

Troca de Dados entre Processos

O Linux oferece uma série de mecanismos para trocar dados entre processos. O mecanismo de pipe padrão do UNIX possibilita que um pro-cesso filho herde um canal de comunicação de seu pai. Dados escritos em uma extremidade do pipe podem ser lidos na outra.

Outro método de compartilhar dados entre processos é a memória compartilhada que oferece um modo extremamente rápido de comunicar gran-des ou pequenos volumes de dados quando utili-zada em conjunto com qualquer outro mecanismo que sincronize sua comunicação.

Reveja os mecanismos no item 2.3 Comunicação entre Processos

Gerência de Módulos

Para carregar um módulo, não basta apenas carregar seu conteúdo binário para a memória do kernel. O sistema deve certificar-se de que todas as referências feitas pelo módulo a símbolos do kernel ou pontos de entrada sejam atualizadas.

O Linux lida com essa atualização de referên-cias dividindo a tarefa de carga do módulo em duas seções separadas: a gerência de seções de código do módulo na memória do kernel e o tratamento dos símbolos aos quais os módulos têm permissão para fazer referência.


Gerência do Processador

A gerência do processador no Linux utiliza dois tipos de política de escalonamento: circular (Round Robin) com prioridades e escalonamento por prioridades.

A política de escalonamento tem a finalidade de permitir o compartilhamento da CPU por vários processos interativos e batch, além de oferecer baixos tempos de respostas para os usuários interativos.

Gerência de Memória

Há dois componentes na gerência de memória no Linux. O primeiro lida com a alocação e liberação de memória física: páginas, grupos de páginas e pequenos blocos de memória. O segundo trata a memória virtual, que é a memória mapeada no es-paço de endereçamento dos processos em execução.

O alocador de páginas no Linux é responsá-vel pela alocação e liberação de todas as páginas físicas e é capaz de alocar intervalos de páginas fisicamente contíguas sob demanda.

O sistema de memória virtual do Linux é responsável pela manutenção do espaço de ende-reçamento visível para cada processo. As páginas virtuais são criadas sob demanda e o sistema de memória virtual gerencia a carga dessas páginas do disco ou seu retorno de volta para o disco conforme necessário.

Uma importante tarefa do sistema de memória virtual é relocar as páginas da memória física para o disco quando existe a necessidade de memória (swap). O Linux não implementa o swapping de processo integral, ele utiliza exclusivamente o mecanismo mais recente de paginação.


Registro de Driver

Uma vez carregado, um módulo não consti-tuirá mais que uma região isolada da memória, a menos que ele faça conhecer ao resto do kernel qual nova funcionalidade ele proporcionará.

O kernel mantém tabelas dinâmicas de todos os drivers conhecidos e oferece um conjunto de rotinas de modo a permitir drivers serem acrescen-tados ou removidos a qualquer momento.


Para saber mais sobre Cases Linux leia o Capítulo 21 (p. 474-507) do livro de:

SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas operacionais com java - conceitos e aplica-ções.Tradução da 6. ed. Rio de Janeiro: Campus, 2005.

Neste livro existe um capítulo dedicado especifica-mente ao Linux, ao contrário de muitos que tratam do Unix em geral. Possui uma abordagem prática com exemplos que facilitam a compreensão. Para saber mais sobre Cases Linux, leia o Capítulo 15 (p. 286-304) do livro de:


Através de ilustrações que auxiliam na compreensão dos tipos de processos, os autores Francis e Luiz Paulo apresentam o assunto de forma clara e com exemplos de situações vividas por usuários.


PARA REFLETIR

Com tantas distribuições Linux disponíveis pense a respeito de quais deveriam ser os critérios de um usuário para decidir qual distribuição utilizar.

RESUMO

No conteúdo 4.1 vimos sobre a gerência do sis-tema de arquivo do sistema operacional no que diz respeito às implementações e organizações de arquivos e diretórios que influi diretamente na se-gurança dos dados de um sistema computacional.Na sequência, no 4.2, conhecemos juntos sobre os princípios de segurança de sistemas operacionais. Estudamos itens que devem ser levados em con-sideração a respeito de segurança em um projeto sobre sistemas operacionais e soluções existentes para garanti-la.

Já no conteúdo 4.3 foram apresentados particulari-dades do Windows, em que, além de um pequeno resumo histórico, analisamos implementações da estrutura do sistema windows e pudemos ver os detalhes de cada componente de suas camadas.Por fim, no 4.4 estudamos sobre cases Linux, vimos como se deu o início de seu desenvolvimento e sua relação com o UNIX, além de suas gerências e particularidades.

173Fundamentos em Sistemas Operacionais

Referências

CAMPOS, Augusto. O que é uma distribuição linux. BR-Linux. Florianópolis, março de 2006. Disponível em <http://br-linux.org/faq-distribuicao>. Acesso em 16 de novembro de 2010.

DEITEL, Paul; DEITEL, Harvey; CHOFFNES, David. Sis-temas operacionais. 3. ed. Prentice Hall Brasil, 2005.

FELITTI, Guilherme. Windows Vista versus XP: quais as principais diferenças. IDG NOW! São Paulo, janeiro de 2007, atualizada em setembro de 2008. Disponí-vel em <http://idgnow.uol.com.br/computacao_pesso-al/2007/01/22/idgnoticia.2007-01-22.9923517569/>. Acesso em 19 de nov. de 2010.

GUIMARÃES, Ângelo de Moura; LAGES, Newton A. de Castilho. Introdução à ciência da computação. 8. ed. Rio de Janeiro: LTC, 1990.

JONES, M. Tim. Anatomia do sistema de arquivos linux. IBM. Longmont, Colorado, Outubro de 2007. Dispo-nível em <http://www.ibm.com/developerworks/br/library/l-linux-filesystem/>. Acesso em 18 de novembro de 2010.


MICROSOFT, Como comparar. 2010. <http://www.mi-crosoft.com/brasil/servidores/windowsserver2003/compare.mspx> (19.11.2010).

OFICINA DA NET. Anderson Villela. O que é Windows Vista. <http://www.oficinadanet.com.br/artigo/259/o_que_e_windows_vista>. Acesso em 19 de nov. de 2010.

174 Fundamentos em Sistemas Operacionais

SILBERSCHATZ, Abraham; GAGNE, Greg; GALVIN, Peter. Sistemas operacionais com java - conceitos e apli-cações. Tradução da 6. ed. Rio de Janeiro: Campus, 2005.

SILVA, Roberto Rodrigues. Linux - sistema de ar-quivos. Viva o Linux. Maringá, Novembro de 2006. Disponível em <http://www.vivaolinux.com.br/artigo/Linux-Sistema-de-arquivos>. Acesso em 17 de novembro de 2010.

SINGH, Simon. O livro dos códigos – a ciência do sigilo – do antigo Egito à criptografia quântica. 7 ed. Rio de Janeiro: Record, 2008.


TANENBAUM, Andrew S. Sistemas operacionais modernos. 2. ed. Rio de Janeiro: Prentice Hall Brasil, 2007.

VILLELA, Anderson. O que é Windows Vista. Ofici-na da Net. São Paulo, abril de 2007. Disponível em <http://www.oficinadanet.com.br/artigo/259/o_que_e_windows_vista>. Acesso em 19 de nov. de 2010.

Windows Server 2008 R2 - Aprenda na prática. Bra-sil, 2010. Microsoft |Technet. Disponível em: <http://technet.microsoft.com/pt-br/ee388302.aspx>. Acesso em 19 de Nov. de 2010.

175Fundamentos em Sistemas Operacionais

Anotações


Anotações

Documents

Fundamentos Em Sistemas Operacionais