Sistemas Operacionais

Prévia do material em texto

Sistemas Sistemas 
operacionaisoperacionais
AUTORIA
Cleber Jose Semensate Santos
Bem vindo(a)!
Olá, esta apostila de Sistemas Operacionais (SO), foi elaborado especialmente para 
você conhecer como este Sistema atua, gerencia e facilita a utilização dos 
computadores.
A apostila está dividida em quatro unidades. Iremos abordar desde os conceitos 
básicos aos mais atuais como a utilização de máquinas virtuais/virtualização.
O objetivo desta apostila não é ensinar como utilizar um SO, mas sim conhecer os 
fundamentos que todos os SO’s devem seguir, não importando o fabricante, tipo de 
licença ou onde ele é usado (em um notebook, celular ou desktop). Logo na primeira 
unidade iremos aprender o que é um sistema operacional e quais deles são mais 
utilizados.
A segunda unidade é dedicada exclusivamente ao gerenciamento de processos. 
Esta unidade será de vital importância para o andamento do curso, pois iremos 
detalhar a forma como o SO desempenha uma das suas principais funções que é 
facilitar a comunicação do hardware com os programas do usuário.
A terceira unidade consistirá na apresentação do gerenciamento de memória e dos 
sistemas de arquivos e com certeza as diferenças entre os SO’s �carão mais claras, 
pois iremos diferenciá-los por meio do detalhamento dos itens desta unidade.
Da unidade II até a unidade IV descreveremos as funcionalidades que todos os 
sistemas operacionais devem possuir. Na quarta unidade abordaremos como o 
mouse, teclado e outros dispositivos de entrada/saída interagem com o sistema 
operacional.
Querido(a) aluno(a), se prepare para esta grande viagem por dentro de um dos itens 
mais importantes do computador.
Vamos lá?
Muito obrigado e bom estudo!
Unidade 1
Introdução ao estudo de
sistemas operacionais
AUTORIA
Cleber Jose Semensate Santos
Introdução
Olá, caro(a) aluno(a)!
Seja bem-vindo(a) ao estudo dos sistemas operacionais (SO’s). Nesta unidade iremos
abordar as de�nições, tipos e os principais SO’s de mercado.
Para de�nirmos sistema operacional (SO), precisamos relembrar as de�nições de
hardware e software:
Hardware: parte física do computador. É tudo aquilo que pode ser tocado.
Exemplo: teclado, mouse, monitor, gabinete, processador, memória entre outros.
Software: parte lógica do computador. Ao contrário do hardware, esta parte não
pode ser tocada. Também chamado de programa ou aplicativo.
Exemplo: sistemas operacionais, processadores de textos, arquivos salvos, planilhas
eletrônicas entre outros.
 Um computador moderno consiste em um ou mais processadores, uma memória
principal, discos, impressoras, um teclado, um mouse, um monitor, interfaces de
rede e vários outros dispositivos de entrada e saída. Como um todo, trata-se de um
sistema complexo. Se todo programador de aplicativos tivesse de compreender
como todas essas partes funcionam em detalhe, nenhum código jamais seria
escrito. Além disso, gerenciar todos esses componentes e usá-los de maneira
otimizada é um trabalho extremamente desa�ador.
  Por essa razão, computadores são equipados com um dispositivo de software
chamado de sistema operacional, cuja função é fornecer aos programas do usuário
um modelo do computador melhor, mais simples e mais limpo, assim como lidar
com o gerenciamento de todos os recursos mencionados.
Conceitos básicos
AUTORIA
Cleber Jose Semensate Santos
Segundo Tanenbaum (2016), é difícil dizer com absoluta precisão o que é um
sistema operacional, além de ele ser o software que opera em modo núcleo — e
mesmo isso nem sempre é verdade. Parte do problema é que os sistemas
operacionais realizam duas funções essencialmente não relacionadas: fornecer a
programadores de aplicativos (e programas aplicativos, claro) um conjunto de
recursos abstratos limpo em vez de recursos confusos de hardware, e gerenciar
esses recursos de hardware. Dependendo de quem fala, você poderá ouvir mais a
respeito de uma função do que de outra. Examinemos as duas então.
O Sistema operacional como uma
máquina estendida
De acordo com Tanenbaum (2016), a arquitetura da maioria dos computadores em
nível de linguagem de máquina é primitiva e complicada de programar,
especialmente para entrada/saída. Para deixar esse ponto mais claro, considere os
discos rígidos modernos do tipo SATA (Serial ATA) usados na maioria dos
computadores.
É claro que nenhum programador são iria querer lidar com esse disco em nível de
hardware. Em vez disso, um software, chamado driver de disco, lida com o hardware
e fornece uma interface para ler e escrever blocos de dados, sem entrar nos
detalhes. Sistemas operacionais contêm muitos drivers para controlar dispositivos
de E/S. Mas mesmo esse nível é baixo demais para a maioria dos aplicativos. Por essa
razão, todos os sistemas operacionais fornecem mais um nível de abstração para se
utilizarem discos: arquivos. Usando essa abstração, os programas podem criar,
escrever e ler arquivos, sem ter de lidar com os detalhes complexos de como o
hardware realmente funciona. TANENBAUM (2016).
Essa abstração é a chave para gerenciar toda essa complexidade. Boas abstrações
transformam uma tarefa praticamente impossível em duas tarefas gerenciáveis. A
primeira é de�nir e implementar as abstrações. A segunda é utilizá-las para
solucionar o problema à mão. Uma abstração que quase todo usuário de
computadores compreende é o arquivo, como mencionado anteriormente. Trata-se
de um fragmento de informação útil, como uma foto digital, uma mensagem de e-
mail, música ou página da web salvas. É muito mais fácil lidar com fotos, e-mails,
músicas e páginas da web do que com detalhes de discos SATA (ou outros).
A função dos sistemas operacionais é criar boas abstrações e então implementar e
gerenciar os objetos abstratos criados desse modo. Neste material, falaremos muito
sobre abstrações. Elas são uma das chaves para compreendermos os sistemas
operacionais. Processadores reais, memórias, discos e outros dispositivos são muito
complicados e apresentam interfaces difíceis, desajeitadas, idiossincráticas e
inconsistentes para as pessoas que têm de escrever softwares para elas utilizarem.
Uma das principais tarefas dos sistemas operacionais é esconder o hardware e em
vez disso apresentar programas (e seus programadores) com abstrações de
qualidade, limpas, elegantes e consistentes com as quais trabalhar. TANENBAUM
(2016).
Deve ser observado que os clientes reais dos sistemas operacionais são os
programas aplicativos. São eles que lidam diretamente com as abstrações
fornecidas pela interface do usuário, seja uma linha de comandos (shell) ou uma
interface grá�ca. Embora as abstrações na interface com o usuário possam ser
similares às abstrações fornecidas pelo sistema operacional, nem sempre esse é o
caso.
Para esclarecer esse ponto, considere a área de trabalho normal do Windows e o
prompt de comando orientado a linhas. Ambos são programas executados no
sistema operacional Windows e usam as abstrações que o Windows fornece, mas
eles oferecem interfaces de usuário muito diferentes. De modo similar, um usuário
de Linux executando Gnome ou KDE vê uma interface muito diferente daquela vista
por um usuário Linux trabalhando diretamente sobre o X Window System, mas as
abstrações do sistema operacional subjacente são as mesmas em ambos os casos.
TANENBAUM (2016).
O Sistema operacional como um
gerenciador de recursos
Para Tanenbaum (2016), o conceito de um sistema operacional como
fundamentalmente fornecendo abstrações para programas aplicativos é uma visão
top-down (abstração de cima para baixo). Uma visão alternativa, bottom-up
(abstração de baixo para cima), sustenta que o sistema operacional está ali para
gerenciar todas as partes de um sistema complexo. Computadores modernos
consistem de processadores, memórias, temporizadores, discos, dispositivos
apontadores do tipo mouse, interfaces de rede, impressoras e uma ampla gama de
outros dispositivos. Na visão bottom-up, a função do sistema operacional é fornecer
uma alocação ordenada e controlada dos processadores, memórias e dispositivosde
E/S entre os vários programas competindo por eles.
Sistemas operacionais modernos permitem que múltiplos programas estejam na
memória e sejam executados ao mesmo tempo. Imagine o que aconteceria se três
programas executados em um determinado computador tentassem todos imprimir
sua saída simultaneamente na mesma impressora. As primeiras linhas de impressão
poderiam ser do programa 1, as seguintes do programa 2, então algumas do
programa 3 e assim por diante. O resultado seria o caos absoluto. O sistema
operacional pode trazer ordem para o caos em potencial armazenando
temporariamente toda a saída destinada para a impressora no disco. Quando um
programa é �nalizado, o sistema operacional pode então copiar a sua saída do
arquivo de disco onde ele foi armazenado para a impressora, enquanto ao mesmo
tempo o outro programa pode continuar a gerar mais saída, alheio ao fato de que a
saída não está realmente indo para a impressora (ainda). TANENBAUM (2016).
Quando um computador tem mais de um usuário, a necessidade de gerenciar e
proteger a memória, dispositivos de E/S e outros recursos é ainda maior, tendo em
vista que os usuários poderiam interferir um com o outro de outra maneira. Além
disso, usuários muitas vezes precisam compartilhar não apenas o hardware, mas a
informação (arquivos, bancos de dados etc.) também. Resumindo, essa visão do
sistema operacional sustenta que a sua principal função é manter um controle
sobre quais programas estão usando qual recurso, conceder recursos requisitados,
contabilizar o seu uso, assim como mediar requisições con�itantes de diferentes
programas e usuários. TANENBAUM (2016).
Tanenbaum (2016), a�rma que o gerenciamento de recursos inclui compartilhá-los
de duas maneiras diferentes: no tempo e no espaço. Quando um recurso é
multiplexado no tempo, diferentes programas ou usuários se revezam usando-o.
Primeiro, um deles usa o recurso, então outro e assim por diante. Por exemplo, com
apenas uma CPU e múltiplos programas querendo ser executados nela, o sistema
operacional primeiro aloca a CPU para um programa, então, após ele ter sido
executado por tempo su�ciente, outro programa passa a fazer uso da CPU, então
outro, e �nalmente o primeiro de novo. Determinar como o recurso é multiplexado
no tempo — quem vai em seguida e por quanto tempo — é a tarefa do sistema
operacional. Outro exemplo da multiplexação no tempo é o compartilhamento da
impressora. Quando múltiplas saídas de impressão estão na �la para serem
impressas em uma única impressora, uma decisão tem de ser tomada sobre qual
deve ser impressa em seguida.
O outro tipo é a multiplexação de espaço. Em vez de os clientes se revezarem, cada
um tem direito a uma parte do recurso. Por exemplo, a memória principal é
normalmente dividida entre vários programas sendo executados, de modo que cada
um pode ser residente ao mesmo tempo (por exemplo, a �m de se revezar usando a
CPU).
Presumindo que há memória su�ciente para manter múltiplos programas, é mais
e�ciente manter vários programas na memória ao mesmo tempo do que dar a um
deles toda ela, especialmente se o programa precisa apenas de uma pequena
fração do total. É claro, isso gera questões de justiça, proteção e assim por diante, e
cabe ao sistema operacional solucioná-las. Outro recurso que é multiplexado no
espaço é o disco. Em muitos sistemas um único disco pode conter arquivos de
muitos usuários ao mesmo tempo. Alocar espaço de disco e controlar quem está
usando quais blocos do disco é uma tarefa típica do sistema operacional.
TANENBAUM (2016).
Estrutura de um sistema 
operacional
AUTORIA
Cleber Jose Semensate Santos
Nas seções a seguir, examinaremos seis estruturas diferentes que foram tentadas, a
�m de termos alguma ideia do espectro de possibilidades. Isso não quer dizer que
esgotaremos o assunto, mas elas dão uma ideia de alguns projetos que foram
tentados na prática. Os seis projetos apresentados por Tanenbaum (2016) e que
discutiremos aqui são: sistemas monolíticos, sistemas de camadas, micronúcleos,
sistemas cliente-servidor, máquinas virtuais e exonúcleos.
Sistemas monolíticos
Nas palavras de Tanenbaum (2016), de longe a organização mais comum, na
abordagem monolítica todo o sistema operacional é executado como um único
programa em modo núcleo. O sistema operacional é escrito como uma coleção de
rotinas, ligadas a um único grande programa binário executável. Quando a técnica é
usada, cada procedimento no sistema é livre para chamar qualquer outro, se este
oferecer alguma computação útil de que o primeiro precisa. Ser capaz de chamar
qualquer procedimento que você quer é muito e�ciente, mas ter milhares de
procedimentos que podem chamar um ao outro sem restrições pode também levar
a um sistema difícil de lidar e compreender. Também, uma quebra em qualquer
uma dessas rotinas derrubará todo o sistema operacional.
Sistemas de camadas
Como aponta Tanenbaum (2016), uma generalização da abordagem da Figura 1.1 é
organizar o sistema operacional como uma hierarquia de camadas, cada uma
construída sobre a camada abaixo dela.
Figura 1.1 Um modelo de estruturação simples para um sistema monolítico. 
Fonte: Elaborado pelo autor.
O primeiro sistema construído dessa maneira foi o sistema THE desenvolvido na
Technische Hogeschool Eindhoven na Holanda por E. W. Dijkstra (1968) e seus
estudantes. O sistema THE era um sistema em lote simples para um computador
holandês, o Electrologica X8, que tinha 32 K de palavras de 27 bits.
Outra generalização do conceito de camadas estava presente no sistema MULTICS.
Em vez de camadas, MULTICS foi descrito como tendo uma série de anéis
concêntricos, com os anéis internos sendo mais privilegiados do que os externos (o
que é efetivamente a mesma coisa).
Quando um procedimento em um anel exterior queria chamar um procedimento
em um anel interior, ele tinha de fazer o equivalente de uma chamada de sistema,
isto é, uma instrução de desvio, TRAP, cujos parâmetros eram cuidadosamente
conferidos por sua validade antes de a chamada ter permissão para prosseguir.
Embora todo o sistema operacional fosse parte do espaço de endereço de cada
processo de usuário em MULTICS, o hardware tornou possível que se designassem
rotinas individuais (segmentos de memória, na realidade) como protegidos contra
leitura, escrita ou execução. TANENBAUM (2016).
Micronúcleos
De acordo com Tanenbaum (2016), a ideia básica por trás do projeto de micronúcleo
é atingir uma alta con�abilidade através da divisão do sistema operacional em
módulos pequenos e bem de�nidos, apenas um dos quais — o micronúcleo — é
executado em modo núcleo e o resto é executado como processos de usuário
comuns relativamente sem poder. Em particular, ao se executar cada driver de
dispositivo e sistema de arquivos como um processo de usuário em separado, um
erro em um deles pode derrubar esse componente, mas não consegue derrubar o
sistema inteiro. Desse modo, um erro no driver de áudio fará que o som �que
truncado ou pare, mas não derrubará o computador.
Em comparação, em um sistema monolítico, com todos os drivers no núcleo, um
driver de áudio com problemas pode facilmente referenciar um endereço de
memória inválido e provocar uma parada dolorosa no sistema instantaneamente.
TANENBAUM (2016).
O sistema tem muitas restrições limitando o poder de cada processo. Como
mencionado, os drivers podem tocar apenas portas de E/S autorizadas, mas o acesso
às chamadas de núcleo também é controlado processo a processo, assim como a
capacidade de enviar mensagens para outros processos.
Processos também podem conceder uma permissão limitada para outros processos
para que o núcleo acesse seus espaços de endereçamento. Como exemplo, um
sistema de arquivos pode conceder uma permissão para que a unidade de disco
deixe o núcleo colocar uma leitura recente de um bloco do disco em um endereço
especí�co dentro do espaço de endereço do sistema de arquivos. A soma de todas
essas restrições é que cada driver e servidor têm exatamente o poder de fazer o seu
trabalho e nada mais, dessa maneiralimitando muito o dano que um componente
com erro pode provocar. TANENBAUM (2016).
O modelo cliente-servidor
REFLITA
Imagine como seria o desenvolvimento de programas se não existissem
os sistemas operacionais?
Sem dúvida nenhuma seria um pouco mais demorado, tendo em vista
que a cada nova implementação, necessitaria de uma nova a
programação e recon�guração dos dispositivos/hardwares a serem
utilizados.
Para Tanenbaum (2016), uma ligeira variação da ideia do micronúcleo é distinguir
duas classes de processos, os servidores, que prestam algum serviço, e os clientes,
que usam esses serviços. Esse modelo é conhecido como o modelo cliente-servidor.
Muitas vezes, a camada mais baixa é a do micronúcleo, mas isso não é necessário. A
essência encontra-se na presença de processos clientes e processos servidores.
A comunicação entre clientes e servidores é realizada muitas vezes pela troca de
mensagens. Para obter um serviço, um processo cliente constrói uma mensagem
dizendo o que ele quer e a envia ao serviço apropriado. O serviço então realiza o
trabalho e envia de volta a resposta. Se acontecer de o cliente e o servidor serem
executados na mesma máquina, determinadas otimizações são possíveis, mas
conceitualmente, ainda estamos falando da troca de mensagens aqui. TANENBAUM
(2016).
Uma generalização óbvia dessa ideia é ter os clientes e servidores sendo executados
em computadores diferentes, conectados por uma rede local ou de grande área,
como descrito na Figura 1.2. Tendo em vista que os clientes comunicam-se com os
servidores enviando mensagens, os clientes não precisam saber se as mensagens
são entregues localmente em suas próprias máquinas, ou se são enviadas através de
uma rede para servidores em uma máquina remota.
No que diz respeito ao cliente, a mesma coisa acontece em ambos os casos: pedidos
são enviados e as respostas retornadas. Desse modo, o modelo cliente-servidor é
uma abstração que pode ser usada para uma única máquina ou para uma rede de
máquinas. TANENBAUM (2016).
Cada vez mais, muitos sistemas envolvem usuários em seus PCs em casa como
clientes e grandes máquinas em outra parte operando como servidores. Na
realidade, grande parte da web opera dessa maneira. Um PC pede uma página na
web para um servidor e ele a entrega. Esse é o uso típico do modelo cliente-servidor
em uma rede. TANENBAUM (2016).
Figura 1.2 O modelo cliente-servidor em uma rede. 
Fonte: Elaborado pelo autor.
Máquinas virtuais
Os lançamentos iniciais do OS/360 foram estritamente sistemas em lote. Não
obstante isso, muitos usuários do 360 queriam poder trabalhar interativamente em
um terminal, de maneira que vários grupos, tanto dentro quanto fora da IBM,
decidiram escrever sistemas de compartilhamento de tempo para ele. O sistema de
compartilhamento de tempo o�cial da IBM, TSS/360, foi lançado tarde, e quando
en�m chegou, era tão grande e lento que poucos converteram-se a ele.
Ele foi �nalmente abandonado após o desenvolvimento ter consumido algo em
torno de US$ 50 milhões (GRAHAM,1970). Mas um grupo no Centro Cientí�co da IBM
em Cambridge, Massachusetts, produziu um sistema radicalmente diferente que a
IBM por �m aceitou como produto. Um descendente linear, chamado z/VM, é hoje
amplamente usado nos computadores de grande porte da IBM, os zSeries, que são
intensamente usados em grandes centros de processamento de dados corporativos,
por exemplo, como servidores de comércio eletrônico que lidam com centenas ou
milhares de transações por segundo e usam bancos de dados cujos tamanhos
chegam a milhões de gigabytes. TANENBAUM (2016).
Exonúcleos
Como aponta Tanenbaum (2016), em vez de clonar a máquina real, como é feito com
as máquinas  virtuais, outra estratégia é dividi-la, ou em outras palavras, dar a cada
usuário um subconjunto dos recursos. Desse modo, uma máquina virtual pode
obter os blocos de disco de 0 a 1.023, a próxima pode �car com os blocos 1.024 a
2.047 e assim por diante.
Na camada de baixo, executando em modo núcleo, há um programa chamado
exonúcleo (ENGLER et al., 1995). Sua tarefa é alocar recursos às máquinas virtuais e
então conferir tentativas de usá-las para assegurar-se de que nenhuma máquina
esteja tentando usar os recursos de outra pessoa. Cada máquina virtual no nível do
usuário pode executar seu próprio sistema operacional, como na VM/370 e no modo
virtual 8086 do Pentium, exceto que cada uma está restrita a usar apenas os
recursos que ela pediu e foram alocados.
A vantagem do esquema do exonúcleo é que ele poupa uma camada de
mapeamento. Nos outros projetos, cada máquina virtual pensa que ela tem seu
próprio disco, com blocos sendo executados de 0 a algum máximo, de maneira que
o monitor da máquina virtual tem de manter tabelas para remapear os endereços
de discos (e todos os outros recursos). Com o exonúcleo, esse remapeamento não é
necessário. O exonúcleo precisa apenas manter o registro de para qual máquina
virtual foi atribuído qual recurso. Esse método ainda tem a vantagem de separar a
multiprogramação (no exonúcleo) do código do sistema operacional do usuário (em
espaço do usuário), mas com menos sobrecarga, tendo em vista que tudo o que o
exonúcleo precisa fazer é manter as máquinas virtuais distantes umas das outras.
TANENBAUM (2016).
Serviços de sistemas
operacionais
AUTORIA
Cleber Jose Semensate Santos
De acordo com Tanenbaum (2016), o sistema operacional é formado por um
conjunto de rotinas (procedimentos) que oferecem serviços aos usuários do sistema
e suas aplicações, bem como outras rotinas do próprio sistema. Esse conjunto de
rotinas é chamado núcleo do sistema ou Kernel. O sistema operacional é um
prestador de serviços ao usuário. As principais funções do núcleo são:
Execução de programas
O sistema operacional é o responsável pelo carregamento dos programas na
memória principal da máquina e executá-los. O programa é o responsável pelo
término de sua própria execução.
Operações de entrada e saída
Como aponta Tanenbaum (2016), durante a sua execução, um programa pode ter
necessidade de se comunicar com meios externos à máquina. Esta operação recebe
o nome de entrada/saída (E/S) - input/output (I/O) e pode envolver qualquer
dispositivo de E/S (monitor, teclado). Como um programa não pode executar estas
operações diretamente, o sistema operacional é o responsável por fornecer meios
adequados para isso.
SAIBA MAIS
Conheça um pouco mais sobre o Sistema Operacional QNX,
desenvolvido
pela empresa canadense Research In Motion Limited (RIM).
Conheça os integrantes do consórcio de empresas que colaboram com
o
desenvolvimento do SO Android. Este grupo é chamado OHA.
ACESSAR ACESSAR
http://www.qnx.com/
http://www.openhandsetalliance.com/
Gerência do sistema de arquivos
Segundo Tanenbaum (2016), os usuários de uma máquina têm necessidade de
realizar acessos aos arquivos pelo nome para saber se eles existem, para apagá-los
ou até para renomeá-los. Um programa em execução necessita realizar a leitura ou
escrita de um arquivo qualquer. O sistema operacional é o responsável por gerenciar
o sistema de arquivos da máquina. Este gerenciamento inclui a alocação de espaço
no dispositivo de armazenamento (disco rígido), a busca otimizada a um
determinado arquivo e o armazenamento de todas as informações necessárias
sobre cada arquivo.
Detecção de erros
De acordo com Tanenbaum (2016), o sistema operacional é o responsável por
detectar erros possíveis que podem comprometer a execução de qualquer
programa e a segurança da máquina. Esses erros podem envolver o próprio
processador, a memória principal (acesso a uma área proibida), os dispositivos de
entrada/saída (falta de papel na impressora), ou até mesmo o programa do usuário
(uma divisão por zero). Para cada tipo de erro, o sistema operacional tem uma ação
apropriada para garantir a exatidão e a consistência do processo de execução.
Alocação de recursos
Tanenbaum (2016), a�rma que o sistema operacional é o responsável pela alocação
dos diversos recursos em sistemas com um ou mais usuários. Tais recursos incluema memória principal, o próprio processador (CPU), arquivos e os dispositivos de I/O. A
alocação deve ser feita da forma mais e�ciente possível para não prejudicar o
desempenho do sistema.
Contabilização e segurança do sistema
De acordo com Tanenbaum (2016), o sistema operacional é o responsável pela
proteção a todo o sistema computacional. Essa proteção se torna necessária tanto
em sistemas monousuários quanto em sistemas multiusuários. A única diferença é a
sua complexidade. Quando vários usuários (sistema multiusuário) estão usando o
sistema, a execução de um programa não pode interferir na execução de outro.
Além disso, o próprio sistema operacional deve ser protegido de erros cometidos
pelos usuários.
Entender estes conceitos básicos e globais de sistemas operacionais é fundamental
para a continuação das unidades que vem a seguir.
Conseguir entender os conceitos que serão passados nas unidades seguintes e
realizar uma analogia com as gerações de computadores e tipos de sistemas
operacionais será de suma importância para o entendimento dos itens a serem
apresentados.
A partir da unidade seguinte entraremos mais a fundo no conhecimento dos
sistemas operacionais, não importando qual versão ou fabricante tenha desenvolvido.
Se prepare para conhecermos mais a fundo os conceitos sobre os sistemas
operacionais, sobre processos e a comunicação entre eles.
Livro
Conclusão - Unidade 1
Filme
Acesse o link
https://www.youtube.com/watch?v=exe1fRcW8X8
Unidade 2
Processos
AUTORIA
Cleber Jose Semensate Santos
Introdução
Prezado(a) estudante, nesta unidade vamos estudar, de forma mais aprofundada, a
estrutura de um sistema operacional, que consiste em:
Gerência do processador/processos.
Gerência de dispositivos.
Gerência de memória.
Gerência de proteção.
Gerência de arquivos.
Nesta Unidade II, vamos trabalhar exclusivamente Gerência do
processador/processos e suas de�nições.
A maioria de nós ao utilizamos os computadores pessoais, temos o costume de
realizar diversas atividades ao mesmo tempo. Podemos trazer aqui clássico exemplo
de navegar na internet, ouvindo uma música e nos conversando com amigos por
meio das redes sociais. Cada um destes comportamentos corresponde a um
processo que é gerenciado pelo Sistema Operacional - SO. É função do SO prover
processos que funcionem sem travamentos e demora. Além dos processos, no
computador existem diversos outros processos que são executados de tempo em
tempo, como por exemplo, o acionamento de um antivírus, que é executada sem
intervenção humana. A maneira e velocidade que este processamento ocorre é
muito rápida e temos a falsa sensação que tudo está sendo executado todos juntos.
Assim sendo, vamos explorar estas de�nições de processos e os detalhes de como o
Sistema Operacional executa todos estes processos.
Bons estudos!
Processos
O conceito mais central em qualquer sistema operacional é o processo: uma
abstração de um programa em execução. Tudo o mais depende desse conceito, e o
projetista do sistema operacional deve ter uma compreensão profunda do que é um
processo o mais cedo possível. Processos são uma das mais antigas e importantes
abstrações que os sistemas operacionais proporcionam. Eles dão suporte à
possibilidade de haver operações (pseudo) concorrentes mesmo quando há apenas
uma CPU disponível, transformando uma única CPU em múltiplas CPUs virtuais.
Sem a abstração de processo, a computação moderna não poderia existir.
Conceito de processo
AUTORIA
Cleber Jose Semensate Santos
De acordo com Tanenbaum (2016), todos os computadores modernos
frequentemente realizam várias tarefas ao mesmo tempo. Considere um servidor da
web, em que solicitações de páginas da web chegam de toda parte. Quando uma
solicitação chega, o servidor confere para ver se a página requisitada está em cache.
Se estiver, ela é enviada de volta; se não, uma solicitação de acesso ao disco é
iniciada para buscá-la. No entanto, do ponto de vista da CPU, as solicitações de
acesso ao disco levam uma eternidade. Enquanto espera que uma solicitação de
acesso ao disco seja concluída, muitas outras solicitações podem chegar.
Se há múltiplos discos presentes, algumas ou todas as solicitações mais recentes
podem ser enviadas para os outros discos muito antes de a primeira solicitação ter
sido concluída. Está claro que algum método é necessário para modelar e controlar
essa concorrência. Processos (e especialmente threads) podem ajudar nisso.
Agora considere um PC de usuário. Quando o sistema é inicializado, muitos
processos são secretamente iniciados, quase sempre desconhecidos para o usuário.
Por exemplo, um processo pode ser inicializado para esperar pela chegada de e-
mails. Outro pode ser executado em prol do programa antivírus para conferir
periodicamente se há novas de�nições de vírus disponíveis.
Além disso, processos explícitos de usuários podem ser executados, imprimindo
arquivos e salvando as fotos do usuário em um pen- drive, tudo isso enquanto o
usuário está navegando na Web. Toda essa atividade tem de ser gerenciada, e um
sistema de multiprogramação que dê suporte a múltiplos processos é muito útil
nesse caso. TANENBAUM (2016).
Em qualquer sistema de multiprogramação, a CPU muda de um processo para
outro rapidamente, executando cada um por dezenas ou centenas de
milissegundos. Enquanto, estritamente falando, em qualquer dado instante a CPU
está executando apenas um processo, no curso de 1s ela pode trabalhar em vários
deles, dando a ilusão do paralelismo.
Às vezes, as pessoas falam em pseudo paralelismo neste contexto, para diferenciar
do verdadeiro paralelismo de hardware dos sistemas multiprocessadores (que têm
duas ou mais CPUs compartilhando a mesma memória física). Ter controle sobre
múltiplas atividades em paralelo é algo difícil para as pessoas realizarem. Portanto,
projetistas de sistemas operacionais através dos anos desenvolveram um modelo
conceitual (processos sequenciais) que torna o paralelismo algo mais fácil de lidar.
TANENBAUM (2016).
Estados de um processo
AUTORIA
Cleber Jose Semensate Santos
Tanenbaum (2016), a�rma que embora cada processo seja uma entidade
independente, com seu próprio contador de programa e estado interno, processos
muitas vezes precisam interagir entre si. Um processo pode gerar alguma saída que
outro processo usa como entrada. No comando shell “cat chapter1 chapter2
chapter3.
| grep tree” o primeiro processo, executando cat, gera como saída a concatenação dos
três arquivos. O segundo processo, executando grep, seleciona todas as linhas
contendo a palavra “tree”. Dependendo das velocidades relativas dos dois processos
(que dependem tanto da complexidade relativa dos programas, quanto do tempo de
CPU que cada um teve), pode acontecer que grep esteja pronto para ser executado,
mas não haja entrada esperando por ele. Ele deve então ser bloqueado até que
alguma entrada esteja disponível. TANENBAUM (2016).
De acordo com Tanenbaum (2016), quando um processo bloqueia, ele o faz porque
logicamente não pode continuar, em geral porque está esperando pela entrada que
ainda não está disponível. Também é possível que um processo que esteja
conceitualmente pronto e capaz de executar seja bloqueado porque o sistema
operacional decidiu alocar a CPU para outro processo por um tempo. Essas duas
condições são completamente diferentes. No primeiro caso, a suspensão é inerente
ao problema (você não pode processar a linha de comando do usuário até que ela
tenha sido digitada). No segundo caso, trata-se de uma tecnicalidade do sistema (não
há CPUs su�cientes para dar a cada processo seu próprio processador privado). Na
Figura 2.1 vemos um diagrama de estado mostrando os três estados nos quais um
processo pode se encontrar:
Figura 2.1 Estados de um processo. 
Fonte: Elaborado pelo Autor.
Em execução (realmente usando a CPU naquele instante).
Pronto (executável, temporariamente parado para deixar outro
processo ser executado).
Bloqueado (incapaz de ser executado até que algum evento externo
aconteça).
 
Os primeirosdois estados são similares. Em ambos os casos, o processo está disposto
a ser executado, apenas no segundo temporariamente não há uma CPU disponível
para ele. O terceiro estado é fundamentalmente diferente dos dois primeiros, pois o
processo não pode ser executado, mesmo que a CPU esteja ociosa e não tenha nada
mais a fazer. Quatro transições são possíveis entre esses três estados.
A transição 1 ocorre quando o sistema operacional descobre que um processo não
pode continuar agora. Em alguns sistemas o processo pode executar uma chamada
de sistema, como em pause, para entrar em um estado bloqueado. Em outros,
incluindo UNIX, quando um processo lê de um pipe ou de um arquivo especial (por
exemplo, um terminal) e não há uma entrada disponível, o processo é
automaticamente bloqueado. TANENBAUM (2016).
As transições 2 e 3 são causadas pelo escalonador de processos, uma parte do sistema
operacional, sem o processo nem saber a respeito delas. A transição 2 ocorre quando
o escalonador decide que o processo em andamento foi executado por tempo
su�ciente, e é o momento de deixar outro processo ter algum tempo de CPU.
A transição 3 ocorre quando todos os outros processos tiveram sua parcela justa e
está na hora de o primeiro processo chegar à CPU para ser executado novamente. O
escalonamento, isto é, decidir qual processo deve ser executado, quando e por
quanto tempo, é um assunto importante que será melhor abordados adiante. Muitos
algoritmos foram desenvolvidos para tentar equilibrar as demandas concorrentes de
e�ciência para o sistema como um todo e justiça para os processos individuais.
A transição 4 veri�ca quando o evento externo pelo qual um processo estava
esperando (como a chegada de alguma entrada) acontece. Se nenhum outro
processo estiver sendo executado naquele instante, a transição 3 será desencadeada
e o processo começará a ser executado. Caso contrário, ele talvez tenha de esperar no
estado de pronto por um intervalo curto até que a CPU esteja disponível e chegue sua
vez. TANENBAUM (2016).
Escalonamento de
processos
AUTORIA
Cleber Jose Semensate Santos
Para Tanenbaum (2016), quando um computador é multiprogramado, ele
frequentemente tem múltiplos processos ou threads competindo pela CPU ao
mesmo tempo. Essa situação ocorre sempre que dois ou mais deles estão
simultaneamente no estado pronto. Se apenas uma CPU está disponível, uma
escolha precisa ser feita sobre qual processo será executado em seguida. A parte do
sistema operacional que faz a escolha é chamada de escalonador, e o algoritmo que
ele usa é chamado de algoritmo de escalonamento.
Muitas das mesmas questões que se aplicam ao escalonamento de processos
também se aplicam ao escalonamento de threads, embora algumas sejam
diferentes. Quando o núcleo gerencia threads, o escalonamento é geralmente feito
por thread, com pouca ou nenhuma consideração sobre o processo ao qual o thread
pertence. TANENBAUM (2016).
Nos velhos tempos dos sistemas em lote com a entrada na forma de imagens de
cartões em uma �ta magnética, o algoritmo de escalonamento era simples: apenas
execute o próximo trabalho na �ta. Com os sistemas de multiprogramação, ele
tornou-se mais complexo porque geralmente havia múltiplos usuários esperando
pelo serviço.
Como o tempo de CPU é um recurso escasso nessas máquinas, um bom
escalonador pode fazer uma grande diferença no desempenho percebido e
satisfação do usuário. Em consequência, uma grande quantidade de trabalho foi
dedicada ao desenvolvimento de algoritmos de escalonamento inteligentes e
e�cientes. TANENBAUM (2016).
Com o advento dos computadores pessoais, a situação mudou de duas maneiras.
Primeiro, na maior parte do tempo há apenas um processo ativo. É improvável que
um usuário preparando um documento em um processador de texto esteja
simultaneamente compilando um programa em segundo plano. Quando o usuário
digita um comando ao processador de texto, o escalonador não precisa fazer muito
esforço para descobrir qual processo executar — o processador de texto é o único
candidato. TANENBAUM (2016).
Segundo, computadores tornaram-se tão rápidos com o passar dos anos que a CPU
di�cilmente ainda é um recurso escasso. A maioria dos programas para
computadores pessoais é limitada pela taxa na qual o usuário pode apresentar a
entrada (digitando ou clicando), não pela taxa na qual a CPU   pode processá-la.
Mesmo as compilações, um importante sorvedouro de ciclos
de CPUs no passado, levam apenas alguns segundos hoje.
Mesmo quando dois programas estão de fato sendo executados ao mesmo tempo,
como um processador de texto e uma planilha, di�cilmente importa qual deles vai
primeiro, pois o usuário provavelmente está esperando que ambos terminem. Como
consequência, o escalonamento não importa muito em PCs simples. É claro que há
aplicações que praticamente devoram a CPU viva. Por exemplo, reproduzir uma
hora de vídeo de alta resolução enquanto se ajustam as cores em cada um dos
107.892 quadros (em NTSC) ou 90.000 quadros (em PAL) exige uma potência
computacional de nível industrial. No entanto, aplicações similares são a exceção em
vez de a regra. TANENBAUM (2016).
Quando voltamos aos servidores em rede, a situação muda consideravelmente.
Aqui, múltiplos processos muitas vezes competem pela CPU, de maneira que o
escalonamento importa outra vez. Por exemplo, quando a CPU tem de escolher
entre executar um processo que reúne as estatísticas diárias e um que serve a
solicitações de usuários, estes �carão muito mais contentes se o segundo receber a
primeira chance de acessar a CPU. TANENBAUM (2016).
Além de escolher o processo certo a ser executado, o escalonador também tem de
se preocupar em fazer um uso e�ciente da CPU, pois o chaveamento de processos é
algo caro. Para começo de conversa, uma troca do modo usuário para o modo
núcleo precisa ocorrer. Então o estado do processo atual precisa ser salvo, incluindo
armazenar os seus registros na tabela de processos para que eles possam ser
recarregados mais tarde. TANENBAUM (2016).
Em alguns sistemas, o mapa de memória precisa ser salvo da mesma maneira. Em
seguida, um novo processo precisa ser selecionado executando o algoritmo de
escalonamento. Após isso, a unidade de gerenciamento de memória precisa ser
recarregada com o mapa de memória do novo processo. Por �m, o novo processo
precisa ser inicializado. Além de tudo isso, a troca de processo pode invalidar o cache
de memória e as tabelas relacionadas, forçando-o a ser dinamicamente recarregado
da memória principal duas vezes (ao entrar no núcleo e ao deixá-lo). De modo geral,
realizar muitas trocas de processos por segundo pode consumir um montante
substancial do tempo da CPU. TANENBAUM (2016).
Comunicação de processos
AUTORIA
Cleber Jose Semensate Santos
Segundo Tanenbaum (2016), processos quase sempre precisam comunicar-se com
outros processos. Há três questões aqui. A primeira, como um processo pode passar
informações para outro. A segunda tem a ver com certi�car-se de que dois ou mais
processos não se atrapalhem, por exemplo, dois processos em um sistema de
reserva de uma companhia aérea cada um tentando �car com o último assento em
um avião para um cliente diferente. A terceira diz respeito ao sequenciamento
adequado quando dependências estão presentes: se o processo A produz dados e o
processo B os imprime, B tem de esperar até que A tenha produzido alguns dados
antes de começar a imprimir.
Em alguns sistemas operacionais, processos que estão trabalhando juntos podem
compartilhar de alguma memória comum que cada um pode ler e escrever. A
memória compartilhada pode encontrar-se na memória principal (possivelmente
em uma estrutura de dados de núcleo) ou ser um arquivo compartilhado; o local da
memória compartilhada não muda a natureza da comunicação ou os problemas
que surgem.
Para ver como a comunicação entre processos funciona na prática, vamos
considerar um exemplo simples, mas comum: um spool de impressão. Quando um
processo quer imprimir um arquivo, ele entra com o nome do arquivo em um
diretóriode spool especial. Outro processo, o daemon de impressão, confere
periodicamente para ver se há quaisquer arquivos a serem impressos, e se houver,
ele os imprime e então remove seus nomes do diretório. TANENBAUM (2016).
Às vezes é necessário manter um recurso de maneira exclusiva para impedir que
outros processos tenham acesso ao mesmo simultaneamente. Em um sistema
operacional multitarefa, a execução de processos de maneira intercalada ou paralela
pode ocasionar situações imprevisíveis. Quando existe interação com o usuário e
esta é a responsável pelo acesso e uso do recurso, �ca mais difícil para um projetista
de SO's predizer quando o processo irá acessar o recurso.
Além disso, quando são considerados sistemas multiprocessadores, dois processos
executando em paralelo poderiam acessar um recurso simultaneamente. Com
todos estes fatores, um método garantido para impedir que dois processos acessem
um recurso crítico faz-se necessário. TANENBAUM (2016).
A solução teórica para o problema do recurso crítico é simples: antes de entrar na
região crítica de código, aquela em que o recurso é manipulado, o recurso é tornado
indisponível ("locked"). Indisponibilizando o recurso, nenhum outro processo pode
entrar na sua região crítica. Uma vez que o processo acabe de ter sua região crítica
executada, o mesmo disponibiliza ("unlocked") o recurso, de forma que outros
processos possam ter acesso. Um processo desejando acessar o recurso
compartilhado necessita apenas veri�car a disponibilidade do mesmo antes de ter
sua região crítica executada. TANENBAUM (2016).
Exclusão mútua
Segundo Tanenbaum (2016), exclusão mútua é o princípio de que só um processo
tem acesso à região crítica em um dado momento. Sempre que um processo está
entre a fase de fazer o teste e a de indisponibilizar o recurso, há uma chance da
exclusão mútua ser violada. Então, devem ser executados o teste e a
indisponibilização em uma única e atômica operação. Uma operação atômica é
aquela que é inteiramente completada antes que um processo perca a CPU.
Implementando uma operação teste-e-atribua de forma atômica em software é
uma tarefa difícil. Até existem algoritmos para isto, mas são grandes e lentos. Uma
operação teste-e-atribua atômica é tipicamente implementada ou por uma
instrução de processador de máquina (test_and_set) ou pelo núcleo do sistema
operacional, que usa operadores de hardware. O sistema operacional pode controlar
o escalonamento de um processo e pode garantir então que este não seja
interrompido.
Semáforos
Como aponta Tanenbaum (2016), em 1965, E. W. Dijkstra sugeriu um novo tipo de
variável, que ele chamava de semáforo. Semáforos são mecanismos que resolvem o
problema de exclusão mútua. Dijkstra propôs ter duas operações nos semáforos,
hoje normalmente chamadas de down e up (generalizações de sleep e wakeup,
respectivamente). A operação down em um semáforo confere para ver se o valor é
maior do que 0. Se for, ele decrementará o valor (isto é, gasta um sinal de acordar
armazenado) e apenas continua. Se o valor for 0, o processo é colocado para dormir
sem completar o down para o momento. Conferir o valor, modi�cá-lo e
possivelmente dormir são feitos como uma única ação atômica indivisível. É
garantido que uma vez que a operação de semáforo tenha começado, nenhum
outro processo pode acessar o semáforo até que a operação tenha sido concluída ou
bloqueada.
Essa atomicidade é absolutamente essencial para solucionar problemas de
sincronização e evitar condições de corrida. Ações atômicas, nas quais um grupo de
operações relacionadas são todas realizadas sem interrupção ou não são executadas
em absoluto, são extremamente importantes em muitas outras áreas da ciência de
computação também.
A operação up incrementa o valor de um determinado semáforo. Se um ou mais
processos estiverem dormindo naquele semáforo, incapaz de completar uma
operação down anterior, um deles é escolhido pelo sistema (por exemplo, ao acaso)
e é autorizado a completar seu down. Desse modo, após um up com processos
dormindo em um semáforo, ele ainda estará em 0, mas haverá menos processos
dormindo nele. A operação de incrementar o semáforo e despertar um processo
também é indivisível. Nenhum processo é bloqueado realizando um up, assim como
nenhum processo é bloqueado realizando um wakeup no modelo anterior.
TANENBAUM (2016).
Semáforos são implementados no sistema operacional e são considerados uma
forma de comunicação entre processos (semáforos também podem ser usados para
sincronização tão bem como para obtenção de exclusão mútua). Da mesma
maneira que SO's diferentes implementam versões diferentes de memória
compartilhada e �las de mensagens, há várias implementações de semáforos.
TANENBAUM (2016).
Monitores
Para facilitar a escrita de programas corretos, Brinch Hansen (1973) e Hoare (1974)
propuseram uma primitiva de sincronização de nível mais alto chamada monitor.
Um monitor é uma coleção de rotinas, variáveis e estruturas de dados que são
reunidas em um tipo especial de módulo ou pacote. Processos podem chamar as
rotinas em um monitor sempre que eles quiserem, mas eles não podem acessar
diretamente as estruturas de dados internos do monitor a partir de rotinas
declaradas fora dele.
Os monitores têm uma propriedade importante que os torna úteis para realizar a
exclusão mútua: apenas um processo pode estar ativo em um monitor em qualquer
dado instante. Monitores são uma construção da linguagem de programação, então
REFLITA
Um processo poderá executar a chamada a uma impressora em
primeiro plano e posteriormente o scanner, todavia jamais o scanner e
depois a impressora.
Um processo pode ser considerado um programa em execução. Por
exemplo: imagine que desejamos ler um e-book(livro) em nosso
computador. Este livro somente poderá ser visto por você na tela
quando ele estiver em execução e para isto ocorra geralmente será
necessário clicar duas vezes rapidamente sob ele para a sua abertura.
Sendo assim, o processador de texto o abrirá. A partir deste instante
temos um processo em execução. Como será que ele entrou em
execução?
o compilador sabe que eles são especiais e podem lidar com chamadas para rotinas
de monitor diferentemente de outras chamadas de rotina. Tipicamente, quando um
processo chama uma rotina do monitor, as primeiras instruções conferirão para ver
se qualquer outro processo está ativo no momento dentro do monitor. Se isso
ocorrer, o processo que chamou será suspenso até que o outro processo tenha
deixado o monitor. Se nenhum outro processo está usando o monitor, o processo
que chamou pode entrar. TANENBAUM (2016).
Cabe ao compilador implementar a exclusão mútua nas entradas do monitor, mas
uma maneira comum é usar um mutex ou um semáforo binário. Como o
compilador, não o programador, está arranjando a exclusão mútua, é muito menos
provável que algo dê errado. De qualquer maneira, a pessoa escrevendo o monitor
não precisa ter ciência de como o compilador arranja a exclusão mútua. Basta saber
que ao transformar todas as regiões críticas em rotinas de monitores, dois processos
jamais executarão suas regiões críticas ao mesmo tempo. TANENBAUM (2016).
Embora os monitores proporcionem uma maneira fácil de alcançar a exclusão
mútua, isso não é su�ciente. Também precisamos de uma maneira para os
processos bloquearem quando não puderem prosseguir. TANENBAUM (2016). 
Problemas clássicos de sincronização de
processos
A literatura de sistemas operacionais está cheia de problemas interessantes que
foram amplamente discutidos e analisados usando variados métodos de
sincronização. Nas seções a seguir, examinaremos 2 dos problemas mais
conhecidos.
O problema do jantar dos �lósofos
Em 1965, Dijkstra formulou e então solucionou um problema de sincronização que
ele chamou de problema do jantar dos �lósofos. Desde então, todos os que
inventaram mais uma primitiva de sincronização sentiram- se obrigados a
demonstrar quão maravilhosa é a nova primitiva exibindo quão elegantemente ela
soluciona o problema do jantar dos �lósofos. O problemaconsiste de: cinco �lósofos
estão sentados em torno de uma mesa circular. Cada �lósofo tem um prato de
espaguete. O espaguete é tão escorregadio que um �lósofo precisa de dois garfos
para comê-lo. Entre cada par de pratos há um garfo.
Figura 2.2 Jantar dos �lósofos. 
Fonte: Adaptado de Tanenbaum (2016).
A vida de um �lósofo consiste em alternar períodos de alimentação e pensamento.
Quando um �lósofo �ca su�cientemente faminto, ele tenta pegar seus garfos à
esquerda e à direita, um de cada vez, não importa a ordem. Se for bem-sucedido em
pegar dois garfos, ele come por um tempo, então larga os garfos e continua a
pensar.
A questão fundamental é se existe a possibilidade de escrever um programa para
cada �lósofo que faça o que deve fazer e jamais �que travado. Suponha que todos
os cinco �lósofos peguem seus garfos esquerdos simultaneamente. Nenhum será
capaz de pegar seus garfos direitos, e haverá um impasse. TANENBAUM (2016).
Poderíamos facilmente modi�car o programa de maneira que após pegar o garfo
esquerdo, o programa confere para ver se o garfo direito está disponível. Se não
estiver, o �lósofo coloca de volta o esquerdo sobre a mesa, espera por um tempo, e
repete todo o processo. Essa proposta também fracassa, embora por uma razão
diferente.
Com um pouco de azar, todos os �lósofos poderiam começar o algoritmo
simultaneamente, pegando seus garfos esquerdos, vendo que seus garfos direitos
não estavam disponíveis, colocando seus garfos esquerdos de volta sobre a mesa,
esperando, pegando seus garfos esquerdos de novo ao mesmo tempo, assim por
diante, para sempre. Uma situação como essa, na qual todos os programas
continuam a executar inde�nidamente, mas fracassam em realizar qualquer
progresso, é chamada de inanição (starvation). TANENBAUM (2016).
Agora você pode pensar que se os �lósofos simplesmente esperassem um tempo
aleatório em vez de ao mesmo tempo fracassarem em conseguir o garfo direito, a
chance de tudo continuar em um impasse mesmo por uma hora é muito pequena.
Essa observação é verdadeira, e em quase todas as aplicações tentar mais tarde não
é um problema.
Por exemplo, na popular rede de área local Ethernet, se dois computadores enviam
um pacote ao mesmo tempo, cada um espera um tempo aleatório e tenta de novo;
na prática essa solução funciona bem. No entanto, em algumas aplicações você
preferiria uma solução que sempre funcionasse e não pudesse fracassar por uma
série improvável de números aleatórios. Pense no controle de segurança em uma
usina de energia nuclear. TANENBAUM (2016).
A maneira de não apresentar impasse nem inanição é proteger os cinco comandos
seguindo a chamada think com um semáforo binário. Antes de começar a pegar
garfos, um �lósofo realizaria um down em mutex. Após substituir os garfos, ele
realizaria um up em mutex. Do ponto de vista teórico, essa solução é adequada. Do
ponto de vista prático, ela tem um erro de desempenho: apenas um �lósofo pode
estar comendo a qualquer dado instante. Com cinco garfos disponíveis, deveríamos
ser capazes de ter dois �lósofos comendo ao mesmo tempo. TANENBAUM (2016).
O problema dos leitores e escritores
O problema do jantar dos �lósofos é útil para modelar processos que estão
competindo pelo acesso exclusivo a um número limitado de recursos, como em
dispositivos de E/S. Outro problema famoso é o problema dos leitores e escritores
(COURTOIS et al., 1971), que modela o acesso a um banco de dados. Imagine, por
exemplo, um sistema de reservas de uma companhia aérea, com muitos processos
competindo entre si desejando ler e escrever. É aceitável ter múltiplos processos
lendo o banco de dados ao mesmo tempo, mas se um processo está atualizando
(escrevendo) o banco de dados, nenhum outro pode ter acesso, nem mesmo os
leitores. TANENBAUM (2016).
Para conseguir acesso ao banco de dados, o primeiro leitor realiza um down no
semáforo. Leitores subsequentes apenas incrementam um contador. À medida que
os leitores saem, eles decrementam o contador, e o último a deixar realiza um up no
semáforo, permitindo que um escritor bloqueado, se houver, entre. Suponha que
enquanto um leitor está usando o banco de dados, aparece outro leitor. Visto que ter
dois leitores ao mesmo tempo não é um problema, o segundo leitor é admitido.
Leitores adicionais também podem ser admitidos se aparecerem. TANENBAUM
(2016).
Suponha que um escritor apareça. O escritor pode não ser admitido ao banco de
dados, já que escritores precisam ter acesso exclusivo, então ele é suspenso. Depois,
leitores adicionais aparecem. Enquanto pelo menos um leitor ainda estiver ativo,
leitores subsequentes serão admitidos. Como consequência dessa estratégia,
enquanto houver uma oferta uniforme de leitores, todos eles entrarão assim que
chegarem. O escritor será mantido suspenso até que nenhum leitor esteja presente.
Se um novo leitor aparecer, digamos, a cada 2 segundos, e cada leitor levar 5
segundos para realizar o seu trabalho, o escritor jamais entrará. TANENBAUM (2016).
Para evitar essa situação, o programa poderia ser escrito de maneira que quando
um leitor chega e um escritor está esperando, o leitor é suspenso atrás do escritor
em vez de ser admitido imediatamente. Dessa maneira, um escritor precisa esperar
por leitores que estavam ativos quando ele chegou, mas não precisa esperar por
leitores que chegaram depois dele. A desvantagem dessa solução é que ela alcança
uma concorrência menor e assim tem um desempenho mais baixo. Courtois et al.
(1971) apresentam uma solução que dá prioridade aos escritores. TANENBAUM
(2016).
Alocação de recursos e impasses
Tanenbaum (2016), a�rma que os sistemas computacionais estão cheios de recursos
que podem ser usados somente por um processo de cada vez. Exemplos comuns
incluem as impressoras. Ter dois processos escrevendo simultaneamente para a
impressora gera uma saída ininteligível. Em consequência, todos os sistemas
operacionais têm a capacidade de conceder (temporariamente) acesso exclusivo a
um processo a determinados recursos. Para muitas aplicações, um processo precisa
de acesso exclusivo a não somente um recurso, mas a vários.
Recursos
Segundo Tanenbaum (2016), uma classe importante de impasses envolve recursos
para os quais algum processo teve acesso exclusivo concedido. Esses recursos
incluem dispositivos, registros de dados, arquivos e assim por diante. Um recurso
pode ser um dispositivo de hardware (por exemplo, uma unidade de Blu-ray) ou um
fragmento de informação (por exemplo, um registro em um banco de dados).
Um computador normalmente terá muitos recursos diferentes que um processo
pode adquirir. Para alguns recursos, várias instâncias idênticas podem estar
disponíveis, como três unidades de Blu-rays. Quando várias cópias de um recurso
encontram-se disponíveis, qualquer uma delas pode ser usada para satisfazer
qualquer pedido pelo recurso. Resumindo, um recurso é qualquer coisa que precisa
ser adquirida, usada e liberada com o passar do tempo.
Há dois tipos de recursos: preemptíveis e não preemptíveis. Um recurso preemptível
é aquele que pode ser retirado do processo proprietário sem causar-lhe prejuízo
algum. A memória é um exemplo de um recurso preemptível. Já um recurso não
preemptível, por sua vez, é um recurso que não pode ser tomado do seu proprietário
atual sem potencialmente causar uma falha. TANENBAUM (2016).
Impasses (Deadlocks)
De acordo com Tanenbaum (2016), um impasse pode ser de�nido formalmente
como a seguir: Um conjunto de processos estará em situação de impasse se cada
processo no conjunto estiver esperando por um evento que apenas outro processo
no conjunto pode causar.
Como todos os processos estão esperando, nenhum deles jamais causará qualquer
evento que possa despertar um dos outros membros do conjunto, e todos os
processos continuam a esperar para sempre. Para esse modelo, presumimos que os
processos têm um único thread e que nenhuma interrupção é possível para
despertar um processo bloqueado. A condição de não haver interrupções é
SAIBA MAIS
Entenda um pouco mais de processos no Windowse como o
gerenciador de tarefa
pode ser o seu grande aliado:
Acompanhe no portar InfoQ Brasil as últimas novidades sobre Sistemas
Operacionais e como eles pode re�etir no nosso dia-a-dia como
usuários:
ACESSAR ACESSAR
http://www.tecmundo.com.br/memoria/3197-o-que-sao-processos-de-um-sistema--operacional-e-por-que-e-importante-saber.htm
https://www.infoq.com/br/os/
necessária para evitar que um processo em situação de impasse seja acordado por,
digamos, um alarme, e então cause eventos que liberem outros processos no
conjunto. TANENBAUM (2016).
Na maioria dos casos, o evento que cada processo está esperando é a liberação de
algum recurso atualmente possuído por outro membro do conjunto. Em outras
palavras, cada membro do conjunto de processos em situação de impasse está
esperando por um recurso que é de propriedade do processo em situação de
impasse. Nenhum dos processos pode executar, nenhum deles pode liberar
quaisquer recursos e nenhum pode ser desperto. O número de processos e o
número e tipo de recursos possuídos e solicitados não têm importância. Esse
resultado é válido para qualquer tipo de recurso, incluindo hardwares e softwares.
Esse tipo de impasse é chamado de impasse de recurso, e é provavelmente o tipo
mais comum. TANENBAUM (2016).
Nesta Unidade você acabou de ter a percepção do quanto é difícil o trabalho de um 
sistema operacional dentro do computador para prover e gerenciar os diversos 
programas executados pelos usuários.
Qual Sistema Operacional você está utilizando neste momento? Caso esteja 
utilizando Windows ou Linux, este é um SO que consegue executar diversos 
processos ao mesmo tempo. E cada um destes processos irão possuir pelo menos um 
thread e cabe aos algoritmos escalonar e gerenciar a utilização de forma ordenada os 
processos dentro da CPU.
Esta estratégia de ordenação entre processos serve para evitar uma condição de 
disputa entre os recursos. Dentre estas estratégias vale a pena citar os semáforos. 
Caso estas estratégias ou escalonamento falhem, iremos ter sérios problemas 
causando os famosos travamentos nos programas e consecutivamente os 
travamentos do sistema operacional. Se for no Windows, a famosa “tela azul”.
Os assuntos trazidos nesta unidade são de vital importância para que você consiga 
garantir rapidez, con�abilidade e disponibilidade em sistemas operacionais.
Conclusão - Unidade 2
Filme
Acesse o link
Livro
https://www.youtube.com/watch?v=plMxWpXhqig
Unidade 3
Gerenciamento de memória
e sistema de arquivos
AUTORIA
Cleber Jose Semensate Santos
Introdução
A memória principal de um computador tem como tarefa a alocação dos softwares
que estão em execução pelo sistema operacional. Nos Programas, por certo período,
�cam os processos que estão em execução, tanto do sistema operacional, quanto
nos softwares que estão sendo utilizados pelos usuários.
De forma geral, os programas são armazenados na memória secundária, para que
possam ser acessados sempre que necessário. Memória secundária são os discos
rígidos, pen drives, CDs, DVDs, entre outros. Estes dispositivos possuem um espaço
generoso de armazenamento a preços bem reduzidos se comparados a memória
principal de um computador, além de armazenar os dados de forma não-volátil, ou
seja, estes dados não se apagam depois que o computador é desligado.
Outra questão a ser discutida, está relacionada à memória e que está no contexto da
gerência de memória é a de permitir a execução de programas que sejam maiores
do que a memória física disponível, utilizando técnicas como a memória virtual e o
overlay.
Veremos também nesta Unidade III os sistemas de arquivos dos sistemas
operacionais. Os arquivos são gerenciados pelo sistema operacional de forma a
auxiliar a utilização pelos usuários. O sistema de arquivos caracteriza-se como a
parte mais visível de um sistema operacional, uma vez que os usuários manipulam
arquivos a todo o momento. Abordaremos nesta Unidade as principais formas para
organização de arquivos, métodos de acesso, assim como, as principais técnicas de
alocação.
Bons estudos!
Gerenciamento de memória
AUTORIA
Cleber Jose Semensate Santos
A memória principal (RAM) é um recurso importante que deve ser cuidadosamente
gerenciado. Apesar de o computador pessoal médio hoje em dia ter 10.000 vezes
mais memória do que o IBM 7094, o maior computador no mundo no início da
década de 1960, os programas estão �cando maiores mais rápido do que as
memórias. A parte do sistema operacional que gerencia (parte da) hierarquia de
memórias é chamada de gerenciador de memória. Sua função é gerenciar
e�cientemente a memória: controlar quais partes estão sendo usadas, alocar
memória para processos quando eles precisam dela e liberá-la quando tiverem
terminado.
Organização de Memória
Conforme Tanenbaum (2016), o valor de um bit tem pouco signi�cado, as memórias
são estruturadas e divididas em conjuntos ordenados de bits, denominados células,
cada uma podendo armazenar uma parte da informação. Se uma célula consiste em
k beta.bits ela pode conter uma em 2k diferente combinação de bits, sendo que
todas as células possuem a mesma quantidade de bits.
Cada célula deve �car num local certo e sabido, ou seja, a cada célula associa-se um
número chamado de seu endereço. Só assim torna-se possível a busca na memória
exatamente do que se estiver querendo a cada momento(acesso aleatório). Sendo
assim, célula pode ser de�nida como a menor parte de memória endereçável.
TANENBAUM (2016).
Se uma memória tem “n” células o sistema de endereçamento numera as células
sequencialmente a partir de zero até “n-1”, sendo que esses endereços são �xos e
representados por números binários. A quantidade de bits em um endereço está
relacionado a máxima quantidade de células endereçáveis. Por exemplo, se um
endereço possui “m” bits o número máximo de células diretamente endereçáveis é
“2m”.
A maioria dos fabricantes de computador padronizaram o tamanho da célula em 8
bits (Byte). Bytes são agrupados em palavras, ou seja, a um grupo de bytes (2,4,6,8
Bytes) é associado um endereço particular. O signi�cado de uma palavra é que a
maioria das instruções operam em palavras inteiras. TANENBAUM (2016).
Os bytes em uma palavra podem ser numerados da esquerda para direita ou da
direita para esquerda. O primeiro sistema, onde a numeração começa no lado de
alta ordem, é chamado de computador big-endian, e o outro de little-endian. Ambas
representações são boas mas quando uma máquina de um tipo tenta enviar dados
para outra, problemas de posicionamento podem surgir. A falta de um padrão para
ordenar os bytes é um grande problema na troca de dados entre máquinas
diferentes.
Swapping
Nas palavras de Tanenbaum (2016), se a memória física do computador for grande o
su�ciente para armazenar todos os processos, os diversos esquemas existentes
bastarão de certa forma. Mas na prática, o montante total de RAM demandado por
todos os processos é muitas vezes bem maior do que pode ser colocado na
memória.
Em sistemas típicos Windows, OS X ou Linux, algo como 50-100 processos ou mais
podem ser iniciados tão logo o computador for ligado. Por exemplo, quando uma
aplicação do Windows é instalada, ela muitas vezes emite comandos de tal forma
que em inicializações subsequentes do sistema, um processo será iniciado somente
para conferir se existem atualizações para as aplicações. Um processo desses pode
facilmente ocupar 5-10 MB de memória.
Outros processos de segundo plano conferem se há e-mails, conexões de rede
chegando e muitas outras coisas. E tudo isso antes de o primeiro programa do
usuário ter sido iniciado. Programas sérios de aplicação do usuário, como o
Photoshop, podem facilmente exigir 500 MB apenas para serem inicializados e
muitos gigabytes assim que começam a processar dados. Em consequência, manter
todos os processos na memória o tempo inteiro exige um montante enorme de
memória e é algo que não pode ser feito se ela for insu�ciente.
Duas abordagens gerais para lidar com a sobrecarga de memória foram
desenvolvidas aolongo dos anos. A estratégia mais simples, chamada de swapping
(troca de processos), consiste em trazer cada processo em sua totalidade, executá-lo
por um tempo e então colocá-lo de volta no disco. Processos ociosos estão
armazenados em disco em sua maior parte, portanto não ocupam qualquer
memória quando não estão sendo executados (embora alguns “despertem”
CONECTE-SE
Que tal consolidar o seu conhecimento sobre sistema de arquivos, em
especial sobre FAT? Con�ra neste vídeo mais sobre este assunto em:
ACESSAR
https://www.youtube.com/watch?v=FUrucbfS0WM&feature=youtu.be
periodicamente para fazer seu trabalho, e então voltam a “dormir”). A outra
estratégia, chamada de memória virtual, estudaremos mais adiante. TANENBAUM
(2016).
A operação de um sistema de troca de processos pode ser descrito assim: de início,
somente o processo A está na memória. Então os processos B e C são criados ou
trazidos do disco. O processo A é devolvido ao disco. Então o processo D é inserido e
o processo B tirado. Por �m, o processo A volta novamente. Como A está agora em
uma posição diferente, os endereços contidos nele devem ser realocados, seja pelo
software quando ele é trazido ou (mais provável) pelo hardware durante a execução
do programa. TANENBAUM (2016).
Quando as trocas de processos criam múltiplos espaços na memória, é possível
combiná-los em um grande espaço movendo todos os processos para baixo, o
máximo possível. Essa técnica é conhecida como compactação de memória. Em
geral ela não é feita porque exige muito tempo da CPU. TANENBAUM (2016).
Um ponto que vale a pena considerar diz respeito a quanta memória deve ser
alocada para um processo quando ele é criado ou trocado. Se os processos são
criados com um tamanho �xo que nunca muda, então a alocação é simples: o
sistema operacional aloca exatamente o que é necessário, nem mais nem menos.
TANENBAUM (2016).
Paginação
REFLITA
Atenção, não confunda as alocações de memória primária (RAM), e as
alocações para memória secundária (disco rígido, por exemplo).
A velocidade dos processadores cresce muito mais rápida do que a
quantidade de armazenamento das memórias RAM. E com isto, mais
processos precisam de espaço na memória. Sem a memória virtual,
di�cilmente conseguiríamos ter um bom desempenho nos
computadores.
Segundo Tanenbaum (2016), a maioria dos sistemas de memória virtual usa uma
técnica chamada de paginação. Em qualquer computador, programas referenciam
um conjunto de endereços de memória. Quando um programa executa uma
instrução como “MOV REG,1000” ele o faz para copiar o conteúdo do endereço de
memória 1000 para REG (ou vice-versa, dependendo do computador).
Esses endereços gerados por computadores são chamados de endereços virtuais e
formam o espaço de endereçamento virtual. Em computadores sem memória
virtual, o endereço virtual é colocado diretamente no barramento de memória e faz
que a palavra de memória física com o mesmo endereço seja lida ou escrita.
Quando a memória virtual é usada, os endereços virtuais não vão diretamente para
o barramento da memória. Em   vez disso, eles vão para uma MMU (Memory
Management Unit — unidade de gerenciamento de memória) que mapeia os
endereços virtuais em endereços de memória física. TANENBAUM (2016).
O espaço de endereçamento virtual consiste em unidades de tamanho �xo
chamadas de páginas. As unidades correspondentes na memória física são
chamadas de quadros de página. As páginas e os quadros de página são
geralmente do mesmo tamanho. TANENBAUM (2016).
Segmentação
Como aponta Tanenbaum (2016), considere o que acontece se um programa tiver
um número muito maior do que o usual de variáveis, mas uma quantidade normal
de todo o resto. A região do espaço de endereçamento alocada para a tabela de
símbolos pode se esgotar, mas talvez haja muito espaço nas outras tabelas. É
necessário encontrar uma maneira de liberar o programador de ter de gerenciar as
tabelas em expansão e contração, da mesma maneira que a memória virtual elimina
a preocupação de organizar o programa em sobreposições (overlays).
Uma solução direta e bastante geral é fornecer à máquina espaços de
endereçamento completamente independentes, que são chamados de segmentos.
Cada segmento consiste em uma sequência linear de endereços, começando em 0
e indo até algum valor máximo. O comprimento de cada segmento pode ser
qualquer coisa de 0 ao endereço máximo permitido. Diferentes segmentos podem e
costumam ter comprimentos diferentes. Além disso, comprimentos de segmentos
podem mudar durante a execução. O comprimento de um segmento de pilha pode
ser aumentado sempre que algo é colocado sobre a pilha e diminuído toda vez que
algo é retirado dela. TANENBAUM (2016).
Como cada segmento constitui um espaço de endereçamento separado, diferentes
segmentos podem crescer ou encolher independentemente sem afetar um ao
outro. Se uma pilha em um determinado segmento precisa de mais espaço de
endereçamento para crescer, ela pode tê-lo, pois não há nada mais atrapalhando
em seu espaço de endereçamento. Claro, um segmento pode �car cheio, mas
segmentos em geral são muito grandes, então essa ocorrência é rara. Para
especi�car um endereço nessa memória segmentada ou bidimensional, o
programa precisa fornecer um endereço em duas partes, um número de segmento
e um endereço dentro do segmento. TANENBAUM (2016).
Uma memória segmentada tem outras vantagens além de simpli�car o tratamento
das estruturas de dados que estão crescendo ou encolhendo. Se cada rotina ocupa
um segmento em separado, com o endereço 0 como o de partida, a ligação das
rotinas compiladas separadamente é bastante simpli�cada. A�nal de contas, todos
os procedimentos que constituem um programa foram compilados e ligados, uma
chamada para a rotina no segmento “n” usará o endereço de duas partes (n, 0) para
endereçar a palavra 0 (o ponto de entrada). TANENBAUM (2016).
Memória virtual
De acordo com Tanenbaum (2016), apesar de os tamanhos das memórias
aumentarem depressa, os tamanhos dos softwares estão crescendo muito mais
rapidamente. Nos anos 1980, muitas universidades executavam um sistema de
compartilhamento de tempo com dúzias de usuários (mais ou menos satisfeitos)
executando simultaneamente em um VAX de 4 MB. Agora a Microsoft recomenda
no mínimo 2 GB para o Windows 8 de 64 bits. A tendência à multimídia coloca ainda
mais demandas sobre a memória.
Como consequência desses desenvolvimentos, há uma necessidade de executar
programas que são grandes demais para se encaixar na memória e há certamente
uma necessidade de ter sistemas que possam dar suporte a múltiplos programas
executando em simultâneo, cada um deles encaixando-se na memória, mas com
todos coletivamente excedendo-a. A troca de processos não é uma opção atraente,
visto que o disco SATA típico tem um pico de taxa de transferência de várias
centenas de MB/s, o que signi�ca que demora segundos para retirar um programa
de 1 GB e o mesmo para carregar um programa de 1 GB. TANENBAUM (2016).
O problema dos programas maiores do que a memória existe desde o início da
computação, embora em áreas limitadas, como a ciência e a engenharia (simular a
criação do universo, ou mesmo um avião novo, exige muita memória). Uma solução
adotada nos anos 1960 foi dividir os programas em módulos pequenos, chamados
de sobreposições. Quando um programa inicializava, tudo o que era carregado na
memória era o gerenciador de sobreposições, que imediatamente carregava e
executava a sobreposição 0.
Quando terminava, ele dizia ao gerenciador de sobreposições para carregar a
sobreposição 1, acima da sobreposição 0 na memória (se houvesse espaço para isso),
ou em cima da sobreposição 0 (se não houvesse). Alguns sistemas de sobreposições
eram altamente complexos, permitindo muitas sobreposições na memória ao
mesmo tempo. As sobreposições eram mantidas no disco e transferidas para dentro
ou para fora da memória pelo gerenciador de sobreposições. TANENBAUM (2016).
Embora o trabalho real de troca de sobreposições do disco para a memória e vice-
versa fosse feitopelo sistema operacional, o trabalho da divisão do programa em
módulos tinha de ser feito manualmente pelo programador. Dividir programas
grandes em módulos pequenos era uma tarefa cansativa, chata e propensa a erros.
Poucos programadores eram bons nisso. Não levou muito tempo para alguém
pensar em passar todo o trabalho para o computador. TANENBAUM (2016).
O método encontrado (FOTHERINGHAM, 1961) �cou conhecido como memória
virtual. A ideia básica é que cada programa tem seu próprio espaço de
endereçamento, o qual é dividido em blocos chamados de páginas. Cada página é
uma série contígua de endereços. Elas são mapeadas na memória física, mas nem
todas precisam estar na memória física ao mesmo tempo para executar o
programa. Quando o programa referência uma parte do espaço de endereçamento
que está na memória física, o hardware realiza o mapeamento necessário
rapidamente. Quando o programa referência uma parte de seu espaço de
endereçamento que não está na memória física, o sistema operacional é alertado
para ir buscar a parte que falta e reexecuta a instrução que falhou.
De certa maneira, a memória virtual é uma generalização da ideia do registrador
base e registrador limite. O 8088 tinha registradores base separados (mas não
registradores limite) para texto e dados. Com a memória virtual, em vez de ter
realocações separadas apenas para os segmentos de texto e dados, todo o espaço
de endereçamento pode ser mapeado na memória física em unidades
razoavelmente pequenas. A memória virtual funciona bem em um sistema de
multiprogramação, com pedaços e partes de muitos programas na memória
simultaneamente. Enquanto um programa está esperando que partes de si mesmo
sejam lidas, a CPU pode ser dada para outro processo. TANENBAUM (2016).
SAIBA MAIS
Memória virtual. O que é? Como con�gurar.
ACESSAR
https://www.youtube.com/watch?v=7EQaEaDibpg
Sistema de arquivos
AUTORIA
Cleber Jose Semensate Santos
Para Tanenbaum (2016), todas as aplicações de computadores precisam armazenar
e recuperar informações. Enquanto um processo está sendo executado, ele pode
armazenar uma quantidade limitada de informações dentro do seu próprio espaço
de endereçamento. No entanto, a capacidade de armazenamento está restrita ao
tamanho do espaço do endereçamento virtual. Para algumas aplicações esse
tamanho é adequado, mas, para outras, ele é pequeno demais.
Um segundo problema em manter informações dentro do espaço de
endereçamento de um processo é que, quando o processo é concluído, as
informações são perdidas. Para muitas aplicações (por exemplo, bancos de dados),
as informações precisam ser retidas por semanas, meses, ou mesmo para sempre.
Perdê-las quando o processo que as está utilizando é concluído é algo inaceitável.
Além disso, elas não devem desaparecer quando uma falha  no computador mata
um processo.
Um terceiro problema é que frequentemente é necessário que múltiplos processos
acessem (partes de) uma informação ao mesmo tempo. Se temos um diretório
telefônico on-line armazenado dentro do espaço de um único processo, apenas
aquele processo pode acessá-lo. A maneira para solucionar esse problema é tornar a
informação em si independente de qualquer processo. TANENBAUM (2016).
Assim, temos três requisitos essenciais para o armazenamento de informações por
um longo prazo:
1. Deve ser possível armazenar uma quantidade muito grande de informações.
2. As informações devem sobreviver ao término do processo que as está
utilizando.
3. Múltiplos processos têm de ser capazes de acessá-las ao mesmo tempo.
Da mesma maneira que vimos como o sistema operacional abstraía o conceito do
processador para criar a abstração de um processo e como ele abstraía o conceito
da memória física para oferecer aos processos espaços de endereçamento (virtuais),
podemos solucionar esse problema com uma nova abstração: o arquivo. Juntas, as
abstrações de processos (e threads), espaços de endereçamento e arquivos são os
conceitos mais importantes relacionados com os sistemas operacionais.
TANENBAUM (2016).
Conceito de Arquivo
Nas palavras de Tanenbaum (2016), arquivos são unidades lógicas de informação
criadas por processos. Um disco normalmente conterá milhares ou mesmo milhões
deles, cada um independente dos outros. Processos podem ler arquivos existentes e
criar novos se necessário. Informações armazenadas em arquivos devem ser
persistentes, isto é, não devem ser afetadas pela criação e término de um processo.
Um arquivo deve desaparecer apenas quando o seu proprietário o remove
explicitamente. Embora as operações para leitura e escrita de arquivos sejam as
mais comuns, existem muitas outras, algumas das quais examinaremos a seguir.
Arquivos são gerenciados pelo sistema operacional. Como são estruturados,
nomeados, acessados, usados, protegidos, implementados e gerenciados são
tópicos importantes no projeto de um sistema operacional. Como um todo, aquela
parte do sistema operacional lidando com arquivos é conhecida como sistema de
arquivos. TANENBAUM (2016).
Do ponto de vista do usuário, o aspecto mais importante de um sistema de arquivos
é como ele aparece, em outras palavras, o que constitui um arquivo, como os
arquivos são nomeados e protegidos, quais operações são permitidas e assim por
diante. Os detalhes sobre se listas encadeadas ou mapas de bits são usados para o
armazenamento disponível e quantos setores existem em um bloco de disco lógico
não interessam, embora sejam de grande importância para os projetistas do sistema
de arquivos. TANENBAUM (2016).
Métodos de Acesso
Como aponta Tanenbaum (2016), os primeiros sistemas operacionais forneciam
apenas um tipo de acesso aos arquivos: acesso sequencial. Nesses sistemas, um
processo podia ler todos os bytes ou registros em um arquivo em ordem,
começando do princípio, mas não podia pular nenhum ou lê-los fora de ordem. No
entanto, arquivos sequenciais podiam ser trazidos de volta para o ponto de partida,
então eles podiam ser lidos tantas vezes quanto necessário. Arquivos sequenciais
eram convenientes quando o meio de armazenamento era uma �ta magnética, em
vez de um disco.
CONECTE-SE
Você conhece a memória cache? Aprenda mais sobre ela neste vídeo.
ACESSAR
https://www.youtube.com/watch?v=Yucz5VVxcuE&feature=youtu.be
Quando os discos passaram a ser usados para armazenar arquivos, tornou-se
possível ler os bytes ou registros de um arquivo fora de ordem, ou acessar os
registros pela chave em vez de pela posição. Arquivos ou registros que podem ser
lidos em qualquer ordem são chamados de arquivos de acesso aleatório. Eles são
necessários para muitas aplicações. Arquivos de acesso aleatório são essenciais para
muitas aplicações, por exemplo, sistemas de bancos de dados. Se um cliente de uma
companhia aérea liga e quer reservar um assento em um determinado voo, o
programa de reservas deve ser capaz de acessar o registro para aquele voo sem ter
de ler primeiro os registros para milhares de outros voos.
Dois métodos podem ser usados para especi�car onde começar a leitura. No
primeiro, cada operação read fornece a posição no arquivo onde começar a leitura.
No segundo, uma operação simples, seek, é fornecida para estabelecer a posição
atual. Após um seek, o arquivo pode ser lido sequencialmente da posição agora
atual. O segundo método é usado no UNIX e no Windows. TANENBAUM (2016).
Atributos de arquivos
Tanenbaum (2016), a�rma que, todo arquivo possui um nome e sua data. Além disso,
todos os sistemas operacionais associam outras informações com cada arquivo, por
exemplo, a data e o horário em que foi modi�cado pela última vez, assim como o
tamanho do arquivo. Chamamos esses itens extras de atributos do arquivo. Algumas
pessoas os chamam de metadados. A lista de atributos apresentada na Tabela 5.1,
varia bastante de um sistema para outro. Nenhum sistema existente tem todos os
atributos, mas cada um está presente em algum sistema.
Os primeiros quatro atributos concernem à proteção do arquivo e dizem quem pode
acessá-lo e quem não pode. Todos os tipos de esquemas são possíveis,