Notas da Aula 2 - Fundamentos de Sistemas Operacionais 1. Ciclo

Notas da Aula 2 - Fundamentos de Sistemas Operacionais
1. Ciclo de Vida de um Processo
Todo processo passa por 3 fases durante sua vida: criação, execução e término. Um processo
pode ser criado por outro processo ou pelo próprio sistema operacional. Por exemplo, quando
um usuário clica em um ícone de um programa em um menu, o processo que implementa o
menu faz uma requisição para a criação de um novo processo (relativo ao programa disparado
pelo usuário). Embora este seja o caso mais comum (um processo criando outro processo),
existem processos especiais no sistema que são criados diretamente pelo kernel do SO. Por
exemplo, no Linux existe o processo init, que é o primeiro processo disparado pelo SO durante
seu carregamento. O processo init, por sua vez, dispara outros processos de acordo com as
configurações do sistema.
Na prática, quem efetivamente cria o processo é sempre o Sistema Operacional. Quando um
processo deseja criar outro processo, ele precisa fazer uma chamada de sistema. Chamadas
de sistema comuns para a criação de novos processos incluem a fork(), a spawn() e a execv().
Ao ser criado, um processo recebe um pid (Process Identifier), um identificador numérico único
que serve para o controle interno do processo pelo SO e para o gerenciamento dos processos
pelos usuários.
A rotina criação de um processo funciona da seguinte forma. O Sistema Operacional recebe
o nome do arquivo que contém o programa a ser executado como parâmetro da chamada
de sistema. O SO verifica se o arquivo realmente existe. Caso exista, o Sistema Operacional
verifica o formato do arquivo. Cada Sistema Operacional utiliza um formato bem definido para
a representação de um programa, que contém, além das instruções a serem executadas, as
definições das variáveis utilizadas no programa (possivelmente incluindo valores iniciais) e
outras informações que possam ser relevantes. Caso o arquivo esteja no formato correto, o SO
aloca uma porção da memória para o novo processo. Esta porção de memória passa a ser o
espaço de endereçamento do processo, algumas vezes denominado de Imagem do Processo
em Memória.
A chamada fork() funciona de uma maneira um pouco diferente. Ao invés de criar um processo
com base nas informações de um arquivo executável, o SO faz uma cópia da imagem do
processo que chamou a função fork() e a coloca em uma outra parte da memória. Em outras
palavras, a imagem do processo que chama a função fork() é duplicada. O novo processo
criado utiliza esta cópia como seu espaço de endereçamento e herda do processo original
todo o estado atual de execução, incluindo os valores dos registradores. O resultado desta
operação, portanto, é a existência de dois processos idênticos (o original e a cópia recémcriada) em memória prontos para execução.
O processo original recebe como valor de retorno da função fork() o pid do processo criado.
Sua execução prossegue imediatamente após à chamada fork(). O processo criado, por sua
vez, começa a ser executado também imediatamente após a função fork(). Porém, para ele o
valor retornado pela chamada fork() é 0. A utilidade da função fork() é a possibilidade de um
processo criar uma cópia idêntica de si mesmo para que esta execute alguma outra tarefa
relacionada ao mesmo programa.
Uma vez que um processo esteja criado, ele passa para a fase de execução. Durante esta
fase, o processo pode executar dois tipos de ação: processamento ou E/S. A primeira ação
de um processo é sempre do tipo processamento, pois para realizar uma operação de E/S é
necessário executar um conjunto mínimo de instruções, especificando o dispositivo desejado,
bem como os parâmetros da operação.
A fase de execução de um processo, portanto, é basicamente uma alternância entre
processamento e E/S. Durante o processamento, um processo pode fazer uma chamada de
sistema, o que o leva a uma ação do tipo E/S. Enquanto esta ação de E/S é executada, uma
interrupção pode ser disparada, informando o fim da operação e fazendo com que o processo
alterne de volta para a ação do tipo processamento.
Existem alguns processos que, teoricamente, não terminam. Processos servidores por exemplo
(e.g., servidores web, servidores de e-mail) são projetados para ficar em um ciclo perpétuo de
execução, no qual eles aguardam requisições, atendem as requisições recebidas e voltam ao
estado original.
Na prática, no entanto, todo processo termina eventualmente. O término de um processo pode
ocorrer pelas seguintes razões:
● Término normal: a tarefa do processo foi concluída.
● Erros: houve algum erro na execução e o processo teve que ser abortado.
● Intervenção de outros processos ou usuários: o usuário ou algum outro processo
deliberadamente requisita ao SO que “mate” o processo.
● Falha de hardware: falta de luz, defeito, etc.
2. Tipos de Processos
Processos podem ser classificados de acordo com seu perfil de utilização do hardware. Um
processo é dito Intensivo em CPU (ou CPU Bound) se, em comparação com seu uso de
operações de E/S, seu uso de processador for muito grande. Em outras palavras, um processo
intensivo em CPU passa a maior parte do seu tempo de execução utilizando o processador.
De maneira similar, um processo é dito Intensivo em E/S (ou I/O Bound) caso seu uso de
operações de E/S seja muito maior que seu uso do processador.
Estas definições não são rigorosas, no sentido de que não há um percentual pré-determinado
de utilização de operações de E/S ou CPU que defina exatamente a classificação de um
dado processo. Por exemplo, processos que trabalham com grandes quantidades de cálculos
numéricos geralmente são classificados como CPU Bound, pois uma vez lidos os dados do
problema a ser resolvido, o processo trabalha quase exclusivamente executando instruções
no processador e manipulando dados em memória principal. Por outro lado, um programa que
realiza cópias de arquivos no disco é geralmente considerado I/O Bound, pois a maior parte
do tempo gasto na execução é aguardando que o disco rígido realize operações de leitura
e escrita. Para alguns processos, a classificação pode não ser tão clara, podendo variar de
acordo com o ponto de vista.
Na prática, a diferenciação entre processos CPU Bound e I/O Bound é importante, pois ela
define o que influencia no desempenho do processo. O desempenho de processos CPU Bound
em geral é influenciado quase exclusivamente pela velocidade de acesso à memória principal
e pelas características de desempenho do processador (frequência, tamanho da cache, etc).
Por outro lado, processos do tipo I/O Bound têm seu desempenho ligado a fatores como a
velocidade dos dispositivos de E/S acessados e velocidade dos barramentos do sistema.
3. Relacionamento Entre Processos
Dois processos diferentes podem ser independentes ou dependentes. Processos são ditos
independentes quando não há qualquer ligação entre eles. Processos podem ser dependentes
por dois motivos:
● eles têm um “grau de parentesco”; ou
● eles compartilham recursos.
Processos podem compartilhar recursos através de chamadas de sistema. Por exemplo,
dois processos podem requisitar ao SO uma área comum de memória para que eles se
comuniquem através de variáveis compartilhadas.
O tipo mais comum de relacionamento entre processos, no entanto, é o “grau de parentesco”.
Quando um processo A requisita ao SO que crie um novo processo B, diz-se que A é o
processo pai de B. De maneira análoga, B é um processo filho de A. Outros termos de
parentesco, como processo avó ou processo neto, são muitas vezes empregados.
Este relacionamento de processos pais e processos filhos cria uma organização lógica de
processos em uma hierarquia. No Linux, por exemplo, todo processo é filho de algum outro
processo, exceto pelo init, que é criado diretamente pelo SO. O processo init é responsável
por iniciar todas as aplicações básicas do sistema. Desta forma, no Linux, o init é a raiz da
hierarquia dos processos de aplicação.
Embora esta hierarquia não seja fundamental para o funcionamento do SO, muitos
sistemas procuram mantê-la pois ela pode tornar certas tarefas do sistema mais fáceis (ou
mais “limpas”). Por exemplo, no momento de desligamento da máquina, o sistema pode
percorer a hierarquia dos processos das folhas (processos mais baixos na hierarquia) até
a raiz, avisando os processos do encerramento. Para que esta hierarquia seja mantida, o
SO precisa definir uma política para manutenção para alterar a árvore quando um processo
termina. Se o processo terminado não for uma folha da hierarquia, o SO precisa decidir o que
fazer com os processos filhos. Algumas possíveis soluções incluem matar os processos filhos
e seus descendentes, fazer com que o processo avó “herde” os processos filhos, postergar o
términdo efetivo do processo até que todos os descendentes tenham terminado (o processo
não é executado, mas é mantido nas informações de gerenciamento do SO), ou simplesmente
deixar que os filhos se tornem “órfãos”, caso a hierarquia não seja fundamental para SO.
4. Estados de um Processo
Durante a fase de execução de um processo, ele pode alternar entre diversos estados. Em um
sistema multiprogramado, por exemplo, existem processos que estão usando o processador
(um único processo, caso a máquina seja monoprocessada) e existem processos que estão
aguardando a oportunidade de usar o processador. Há ainda processos que estavam utilizando
o processador, porém requisitaram uma operação de E/S e agora se encontram bloqueados,
aguardando o término da operação. Nota-se, portanto, que existem ao menos três estados de
um processo em um sistema:
● Estado executando: processo está atualmente utilizando o processador.
● Estado apto: processo está pronto para usar o processador, porém não está atualmente
em execução.
● Estado bloqueado: processo não pode atualmente utilizar o processador pois está
aguardando o término de uma operação de E/S.
Processos podem passar do estado executando para o estado bloqueado ao requisitarem uma
operação de E/S durante a execução. Uma transição do estado executando para o estado
apto pode ocorrer quando o slice de tempo do processo se esgota, por exemplo. Um processo
no estado apto pode passar para o estado executando quando o SO o escolhe para utilizar o
processador. A partir do estado bloqueado, um processo pode passar ao estado apto quando
sua operação de E/S termina. Note que, neste caso, uma transição direta para o estado
executando também seria possível, dependendo da política de escalonamento do SO.
Algumas transições são impossíveis. Por exemplo, um processo no estado apto não pode
passar diretamente para o estado bloqueado. Isso porque para chegar ao estado bloqueado
o processo precisa requisitar uma operação de E/S, o que requer que ele esteja no estado
executando.
Além destes três estados básicos, pode-se considerar também os estados criação e término.
Como discutido anteriormente, a criação de um processo consiste em uma série de etapas.
Logo, existe um tempo não desprezível entre o momento de requisição de criação de um
processo e o instante em que este processo passa a estar apto. Da mesma forma, o término de
um processo é composto por várias etapas, podendo também ser considerado um estado.
Há ainda a possibilidade de um processo não estar em nenhum dos 5 estados já mencionados.
Para um processo estar em execução ou apto para execução, ele necessariamente deve estar
carregado em memória principal (pois o processador precisa buscar as instruções em memória
principal para executá-las). No entanto, pode ocorrer de um processo do sistema não estar em
memória principal. Basicamente, isso ocorre por dois motivos:
1. Não há memória principal suficiente para acomodar o processo que está sendo criado
no momento. Neste caso, o SO pode decidir prosseguir com a criação do processo,
alocando a imagem do processo em uma área de memória secundária.
2. O processo estava em memória principal, mas para liberar memória (por exemplo, para
um novo processo) o SO decide retirá-lo da memória principal e colocá-lo em uma área
da memória secundária. Esta operação é conhecida como swap e será estudada em
detalhes no Capítulo 7.
Em ambos os casos, o processo colocado em memória secundária não pode ser executado.
Logo, ele não está nos estados apto nem executando. No primeiro caso, o processo também
certamente não está no estado bloqueado, já que ele foi recém-criado. Os estados criação e
término também não são opções. Este, portanto, é um novo estado, denominado suspenso.
Em outras palavras, um processo está no estado suspenso quando sua imagem é colocada em
memória secundária.
O estado suspenso às vezes é visto como dois estados separados: o apto suspenso e o
bloqueado suspenso. A diferença entre estes estados é simples. Um processo apto suspenso é
aquele que foi suspenso (colocado em memória secundária) quando estava no estado apto, ou
imediatamente após sua criação (o processo poderia começar a ser executado). Um processo
bloqueado suspenso é aquele que estava no estado bloqueado antes de ser suspenso.
Quando a operação de E/S requisitada por um processo no estado bloqueado suspenso
termina, este processo passa a estar apto suspenso. Por outro lado, é impossível um processo
apto suspenso passar diretamente para o estado bloqueado suspenso, já que seria necessário
que o processo passasse pelo estado executando para requisitar uma operação de E/S.
A utilidade de se dividir o estado suspenso em dois estados está na gerência do SO. Quando
um espaço de memória principal suficientemente grande para alocar um processo fica vago
(e.g., um processo em memória principal terminou sua execução), o SO pode escolher um
processo suspenso e colocá-lo em memória principal. Um critério razoável para escolha seria
evitar processos que estão suspensos porém ainda esperam pelo término de uma operação
de E/S. Um processo nestas condições não estaria apto a utilizar o processador, mesmo se
estivesse em memória principal. Logo, processos aptos suspensos são candidatos melhores a
serem trazidos para memória principal.
A existência ou não de transições entre cada um dos estados depende das necessidades e
capacidades do SO. Algumas transições são obrigatórias, como do estado apto para o estado
executando. Outras são impossíveis, como do estado bloqueado suspenso para o estado
apto. Porém há várias transições que são discutíveis. Ter mais transições significa uma maior
flexibilidade. Ao mesmo tempo, quando maior o número de transições, mais complexo é o
gerenciamento do SO.