Universidade Eduardo Mondlane

Faculdade de Engenharia

Departamento de Electrotécnica

Tema: Núcleo de um sistema multiprogramado (sistema UNIX)

Discentes: Novela, Manuel João de Matos

Docente: Eng.Edson Cossa

Maputo: aos 23 Abril de 2020

Índice
1 Introdução............................................................................................................................................1
1.1 Contextualização.........................................................................................................................1
1.2 Objectivos....................................................................................................................................1
1.3 Metodologia................................................................................................................................1
2 Criação de Processos...........................................................................................................................2
2.1 Concorrência e sincronização......................................................................................................2
2.1.1 Concorrência........................................................................................................................3
2.1.2 Sincronização.......................................................................................................................3
2.2 Escalonamento de processos.......................................................................................................4
2.3 Interrupções de Processos...........................................................................................................5
3 Conclusão............................................................................................................................................8
4 Bibliografia..........................................................................................................................................9
1 Introdução
No presente trabalho são abordadas as questões de processos que o núcleo de um sistema
multiprogramado deve executar para manter o sistema operativo e o sistema computacional no
geral funcionando.

1.1 Contextualização

O núcleo de um sistema multiprogramado, especificamente o Unix, deve garantir toda a

manutenção e gestão de processos do sistema operacional, fazendo a comunicação com o
hardware.

1.2 Objectivos

 Geral:

Apresentação do núcleo de um sistema multiprogramado (sistema UNIX).

 Específicos:
Descrever a gestão de eventos que é feita pelo núcleo de um sistema multiprogramado.
Descrever as Interrupções de Processos
Descrever a Concorrência e sincronização de Processos

1.3 Metodologia

Pesquisa em manuais da cadeira;

2 Criação de Processos.

Sistemas operacionais precisam de alguma maneira para criar processos. Em sistemas muito
simples, ou em sistemas projectados para executar apenas uma única aplicação (por exemplo, o
controlador em um forno microondas), pode ser possível ter todos os processos que serão em
algum momento necessários quando o sistema for ligado. Em sistemas para fins gerais, no
entanto, alguma maneira é necessária para criar e terminar processos, na medida do necessário,
durante a operação.

Tanto no sistema UNIX quanto no Windows, após um processo ser criado, o pai e o filho têm
os seus próprios espaços de endereços distintos. Se um dos dois processos muda uma palavra no
seu espaço de endereço, a mudança não é visível para o outro processo. No UNIX, o espaço de
endereço inicial do filho é uma cópia do espaço de endereço do pai, mas há definitivamente dois
espaços de endereços distintos envolvidos; nenhuma memória para escrita é compartilhada.
Algumas implementações UNIX compartilham o programa de texto entre as duas, tendo em vista
que isso não pode ser modificado. Alternativamente, o filho pode compartilhar toda a memória do
pai, mas nesse caso, a memória é compartilhada no sistema copy-on-write (cópia-na- -escrita), o
que significa que sempre que qualquer uma das duas quiser modificar parte da memória, aquele
pedaço da memória é explicitamente copiado primeiro para certificar-se de que a modificação
ocorra em uma área de memória privada. Novamente, nenhuma memória que pode ser escrita é
compartilhada. É possível, no entanto, que um processo recentemente criado compartilhe de alguns
dos outros recursos do seu criador, como arquivos abertos. No Windows, os espaços de endereços
do pai e do filho são diferentes desde o início.

2.1 Concorrência e sincronização

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 pseudoparalelismo neste contexto, para diferenciar do verdadeiro paralelismo
de hardware dos sistemas multiprocessadores (que têm duas ou mais CPU’s compartilhando a
mesma memória física). Ter controle sobre múltiplas actividades em paralelo é algo difícil para
as pessoas realizarem. Portanto, projectistas de sistemas.

2.1.1 Concorrência

Um processo é apenas uma instância de um programa em execução, incluindo os valores

atuais do contador do programa, registadores e variáveis. Conceitualmente, cada processo tem
sua própria CPU virtual. Na verdade, a CPU real troca a todo momento de processo em processo,
mas, para compreender o sistema, é muito mais fácil pensar a respeito de uma colecção de
processos sendo executados em (pseudo) paralelo do que tentar acompanhar como a CPU troca
de um programa para o outro. Esse mecanismo de trocas rápidas é chamado de
multiprogramação

2.1.2 Sincronização

Com o chaveamento rápido da CPU entre os processos, a taxa pela qual um processo
realiza a sua computação não será uniforme e provavelmente nem reproduzível se os mesmos
processos forem executados outra vez. Desse modo, processos não devem ser programados com
suposições predefinidas sobre a temporização. Considere, por exemplo, um processo de áudio
que toca música para acompanhar um vídeo de alta qualidade executado por outro dispositivo.
Como o áudio deve começar um pouco depois do que o vídeo, ele sinaliza ao servidor do vídeo
para começar a execução, e então realiza um laço ocioso 10.000 vezes antes de executar o áudio.
Se o laço for um temporizador confiável, tudo vai correr bem, mas se a CPU decidir trocar para
outro processo durante o laço ocioso, o processo de áudio pode não ser executado de novo até
que os quadros de vídeo correspondentes já tenham vindo e ido embora, e o vídeo e o áudio
ficarão irritantemente fora de sincronia. Quando um processo tem exigências de tempo real,
críticas como essa, isto é, eventos particulares, têm de ocorrer dentro de um número específico
de milissegundos e medidas especiais precisam ser tomadas para assegurar que elas ocorram. Em
geral, no entanto, a maioria dos processos não é afectada pela multiprogramação subjacente da
CPU ou as velocidades relativas de processos diferentes.

2.2 Escalonamento de processos.

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. Esses tópicos formam o assunto a ser tratado nas seções a seguir. 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 gerência threads,
o escalonamento é geralmente feito por thread, com pouca ou nenhuma consideração sobre o
processo ao qual o thread pertence.

Examinaremos agora o algoritmo de escalonamento do Linux. Para começar, os threads do

Linux são de núcleo, de maneira que o escalonamento é baseado em threads, não processos. O
Linux distingue três classes de threads para fins de escalonamento: 1. FIFO em tempo real. 2.
Escalonamento circular em tempo real. 3. Tempo compartilhado. Threads do tipo FIFO em
tempo real são os de prioridade mais alta e não sofrem preempção exceto por um thread FIFO
em tempo real recentemente pronto com uma prioridade mais alta. Threads de escalonamento
circular em tempo real são os mesmos que os threads FIFO em tempo real, exceto que eles têm
um quanta de tempo associado a eles e são passíveis de preempção pelo relógio. Se múltiplos
threads de escalonamento circular em tempo real estão prontos, cada um é executado durante o
seu quantum, após o qual ele volta durante fim da lista de threads de escalonamento circular em
tempo real. Nenhuma dessas classes é realmente em tempo real de qualquer maneira. Limites de
tempo não podem ser especificados e garantias não são dadas. Essas classes simplesmente têm
uma prioridade mais alta do que os threads na classe de tempo compartilhado padrão. A razão de
o Linux as chamar em tempo real é que o Linux está em conformidade com o padrão P1003.4
(extensões em “tempo real” para o UNIX) que usa esses nomes. Os threads em tempo real são
internamente representados por níveis de prioridade de 0 a 99, sendo 0 o nível de prioridade em
tempo real mais alto e 99 o mais baixo. Os threads convencionais, não em tempo real, formam
uma classe em separado e são escalonados por um algoritmo diferente, de maneira que não
competem com os threads em tempo real. Internamente, esses threads são associados com níveis
de prioridade de 100 a 139, isto é, o Linux distingue internamente entre 140 níveis de prioridade
(para tarefas em tempo real ou não). Assim como para threads de escalonamento circular em
tempo real, o Linux aloca tempo de CPU para as tarefas que não são em tempo real com base em
suas exigências e níveis de prioridade.

Seu funcionamento interno é relacionado de perto com o projecto da fila de execução

(runqueue), uma estrutura de dados fundamental usada pelo escalonador para controlar todas as
tarefas executáveis no sistema e seleccionar a seguinte a ser executada. Uma fila de execução é
associada com cada CPU no sistema. Historicamente, um escalonador popular do Linux foi o
escalonador O(1). Ele recebeu esse nome porque era capaz de realizar operações de
gerenciamento de tarefas, como seleccionar uma tarefa ou colocar uma tarefa na fila de
execuções, em tempo constante, independentemente do número total de tarefas no sistema. No
escalonador O(1), a fila de execução é organizada em dois arranjos, activo e expirado. Como
mostrado na Figura 10.10(a), cada um desses é um arranjo de 140 cabeçalhos de listas, cada qual
correspondendo a uma prioridade diferente. Cada cabeçalho de lista aponta para uma lista
duplamente encadeada de processos em uma determinada prioridade. A operação básica do
escalonador pode ser descrita como a seguir. O escalonador escolhe uma tarefa da lista de
prioridade mais alta no arranjo activo. Se a fatia de tempo — quantum — expirar, ela é movida
para a lista expirada (potencialmente em um nível de prioridade diferente). Se a tarefa é
bloqueada, por exemplo, para esperar por um evento de E/S, antes que sua fatia de tempo expire,

2.3 Interrupções de Processos

No nível do hardware, as interrupções funcionam como a seguir. Quando um dispositivo de E/S

termina o trabalho dado a ele, gera uma interrupção (presumindo que as interrupções tenham
sido habilitadas pelo sistema operacional). Ele faz isso enviando um sinal pela linha de
barramento à qual está associado. Esse sinal é detectado pelo chip controlador de interrupções na
placa-mãe, que então decide o que fazer. Se nenhuma outra interrupção estiver pendente, o
controlador de interrupção processa a interrupção imediatamente. No entanto, se outra
interrupção estiver em andamento, ou outro dispositivo tiver feito uma solicitação simultânea em
uma linha de requisição de interrupção de maior prioridade no barramento, o dispositivo é
simplesmente ignorado naquele momento. Nesse caso, ele continua a gerar um sinal de
interrupção no barramento até ser atendido pela CPU. Para tratar a interrupção, o controlador
coloca um número sobre as linhas de endereço especificando qual dispositivo requer atenção e
repassa um sinal para interromper a CPU. O sinal de interrupção faz a CPU parar aquilo que ela
está fazendo e começar outra atividade. O número nas linhas de endereço é usado como um
índice em uma tabela chamada de vetor de interrupções para buscar um novo contador de
programa. Esse contador de programa aponta para o início da rotina de tratamento da interrupção
correspondente. Em geral, interrupções de software (traps ou armadilhas) e de hardware usam o
mesmo mecanismo desse ponto em diante, muitas vezes compartilhando o mesmo vector de
interrupções. A localização do vector de interrupções pode ser estabelecida fisicamente na
máquina ou estar em qualquer lugar na memória, com um registador da CPU (carregado pelo
sistema operacional) apontando para sua origem. Logo após o início da execução, a rotina de
tratamento da execução reconhece a interrupção escrevendo um determinado valor para uma das
portas de E/S do controlador de interrupção. Esse reconhecimento diz ao controlador que ele está
livre para gerar outra interrupção.

Ao fazer a CPU atrasar esse reconhecimento até que ela esteja pronta para lidar com a
próxima interrupção, podem ser evitadas condições de corrida envolvendo múltiplas (quase
simultâneas) interrupções. Como nota, alguns computadores (mais velhos) não têm um
controlador de interrupções centralizado, de maneira que cada controlador de dispositivo solicita
as suas próprias interrupções. O hardware sempre armazena determinadas informações antes de
iniciar o procedimento de serviço. Quais informações e onde elas são armazenadas varia muito
de CPU para CPU. No mínimo, o contador do programa deve ser salvo, de maneira que o
processo interrompido possa ser reiniciado. No outro extremo, todos os registadores visíveis e
um grande número de registadores internos podem ser salvos também. Uma questão é onde
salvar essas informações. Uma opção é colocá-las nos registadores internos que o sistema
operacional pode ler conforme a necessidade. Um problema com essa abordagem é que então o
controlador de interrupções não pode ser reconhecido até que todas as informações
potencialmente relevantes tenham sido lidas, a fim de que uma segunda informação não
sobreponha os registadores internos durante o salvamento. Essa estratégia leva a longos períodos
de tempo desperdiçados quando as interrupções são desabilitadas e possivelmente a interrupções
e dados perdidos. Em consequência, a maioria das CPUs salva as informações em uma pilha. No
entanto, essa abordagem também tem problemas.
3 Conclusão
Neste trabalho ficamos a saber da gestão de eventos que é feita no núcleo de um sistema
multiprogramado, Onde vimos que as chamadas do sistema podem ser feitas em threads que são
executas dentro do processador e que são criadas durante a execução de um processo .
Entretanto, As interrupções são eventos que são causados a nível do hardware, sendo assim é um
evento que ocorre a nível dos dispositivos mas que o núcleo do sistema deve ser capaz de
gerenciar.

Sobre a concorrência e sincronização de processos vimos que o núcleo do sistema esta

capacitado com algoritmos de gestão de criação de processos que fazem com que a concorrência
de processos não seja algo de alto custo de hardware, assim o núcleo do processo faz a melhoria
no desempenho, garantido uma sincronização de processos usando a pilha de processos o que
organiza a sequencia de execução dos processos.

O Escalonamento e As Interrupções de Processos fazem o balanceamento de recursos do

computador visto que a CPU executa um e somente um processo de cada vez. Desse modo o
núcleo de um sistema multiprogramado deve ser capaz de fazer a gestão dos eventos de criação
de processos.
4 Bibliografia
ARON, M.; DRUSCHEL, P. Soft Timers: Efficient Microsecond Software Timer Support for
Network Processing. Proc. 17th Symp. on Operating Systems Principles, ACM, p. 223-246,
1999.

ARPACI-DUSSEAU, R.; ARPACI-DUSSEAU, A. Operating Systems: Three Easy Pieces.

Madison: Arpacci-Dusseau, 2013.

BOYD-WICKIZER, S. et al. Corey: an Operating System for Many Cores. Proc. Eighth Symp.
on Operating Systems Design and Implementation, USENIX, p. 43-57, 2008.

CLEMENTS, A. T. et al. The Scalable Commutativity Rule: Designing Scalable Software for
Multicore Processors. Proc. 24th Symp. on Operating Systems Principles, ACM, p. 1-17, 2013

HAUSER, C. et al. Using Threads in Interactive Systems: A Case Study. Proc. 14th Symp. on
Operating Systems Principles, ACM, p. 94-105, 1993.