Resumo: Sistemas Operacionais Abertos Prof. Michael A. Pontes Processos Um processo é um programa em execução. Enquanto um processo é executado, ele muda de estado. O estado de um processo é definido pela atividade atual desse processo. Cada processo pode estar em um dos seguintes estados: novo (new), pronto (ready), executando (running), aguardando (waiting) ou terminado (terminated). Cada processo é representado no sistema operacional por seu próprio bloco de controle de processo (PCB). Um processo, quando não estiver sendo executado, é colocado em alguma fila de espera. Existem duas classes principais de filas em um sistema operacional: fila de requisição de E/S e a fila de prontos (ready queue). A fila de prontos contém todos os processos que estão prontos para serem executados e aguardando pela CPU. Cada processo é representado por um PCB, e os PCBs podem ser vinculados para formar uma fila de prontos. O escalonamento de longo prazo (tarefas) é a seleção de processos para que tenham permissão para disputar a CPU. Normalmente, o escalonamento de longo prazo é bastante influenciado por considerações de alocação de recursos, em especial o gerenciamento de memória. O escalonamento de curto prazo (CPU) é a seleção de um processo a partir da fila de prontos. Os processos na maioria dos sistemas podem ser executados simultaneamente. Existem vários motivos para permitir a execução simultânea: compartilhamento de informações, agilidade da computação, modularidade e conveniência. A execução concorrente exige um mecanismo para a criação e a exclusão de processos. Os processos em execução no sistema operacional podem ser processos independentes ou processos cooperativos. Os processos cooperativos precisam ter meios de comunicação entre si. A comunicação é obtida por meio de dois esquemas complementares: memória compartilhada e sistemas de mensagem. O método de memória compartilhada exige que os processos em comunicação compartilhem algumas variáveis. Os processos deverão trocar informações por meio dessas variáveis compartilhadas. Em um sistema de memória compartilhada, a responsabilidade por fornecer comunicação recai sobre os programadores de aplicações; o sistema operacional só precisa oferecer a memória compartilhada. O método do sistema de mensagens permite aos processos trocarem mensagens. A responsabilidade por fornecer a comunicação pode ficar com o próprio sistema operacional. Esses dois esquemas não são mutuamente exclusivos, podendo ser usados ao mesmo tempo dentro de um único sistema operacional. A comunicação nos sistemas cliente-servidor pode utilizar (1) sockets, (2) remote procedure calls (RPCs) ou (3) o remote method invocation (RMI) da Java. Um socket é definido como uma extremidade para comunicação. Uma conexão entre um par de aplicações consiste em um par de sockets, um em cada ponta do canal de comunicação. RPCs são outra forma de [1]
comunicação distribuída. Uma RPC ocorre quando um processo (ou thread) chama um procedimento em uma aplicação remota. RMI é a versão Java de uma RPC. RMI permite que uma thread invoque um método em um objeto remoto da mesma forma como invocaria um método em um objeto local. A principal distinção entre RPC e RMI é que, em RPC, os dados são passados a um procedimento remoto na forma de uma estrutura de dados comum, enquanto a RMI permite que os objetos sejam passados nas chamadas ao método remoto. [2]
Threads Um thread é um fluxo de controle dentro de um processo. Um processo multithreads contém diversos fluxos de controle diferentes dentro do mesmo espaço de endereços. Os benefícios do uso de multithreads incluem maior responsividade ao usuário, compartilhamento de recursos dentro do processo, economia e a capacidade de tirar proveito das arquiteturas multiprocessadas. As threads no nível do usuário são threads visíveis ao programador e desconhecidas do kernel. Uma biblioteca de threads no espaço do usuário gerencia as threads no nível do usuário. O kernel do sistema operacional aceita e gerencia as threads no nível do kernel. Em geral, as threads no nível do usuário são mais rápidas de criar e gerenciar do que as threads de kernel. Três tipos diferentes de modelos relacionam as threads de usuário e de kernel. O modelo muitos-para-um associa muitas threads de usuário a uma única thread de kernel. O modelo um-para-um associa cada thread de usuário a uma thread de kernel correspondente. O modelo muitos-para-muitos multiplexa muitas threads de usuário a um número menor ou igual de threads de kernel. Os programas multithreads apresentam muitos desafios para o programador, incluindo a semântica das chamadas de sistema fork( ) e exec( ). Outras questões incluem o cancelamento da thread, o tratamento de sinais e os dados específicos da thread. A maior parte dos sistemas operacionais modernos oferece suporte do kernel para as threads; entre eles estão Windows NT e Windows XP, Solaris e Linux. A API Pthreads oferece um conjunto de funções para criar e gerenciar threads no nível do usuário. Java oferece uma API semelhante para dar suporte às threads. Contudo, como as threads Java são controladas pela JVM, e não pela biblioteca de threads no nível do usuário ou kernel, elas não estão sob a categoria de threads no nível do usuário ou do kernel. [3]
Escalonamento de CPU O escalonamento de CPU é a tarefa de selecionar um processo em espera na fila de prontos e alocar a CPU para ele. A CPU é alocada ao processo selecionado pelo despachante. O escalonamento FCFS (First Come First Served) é o algoritmo de escalonamento mais simples, mas pode fazer com que processos curtos esperem pelos processos muito longos. O escalonamento SJF (Shortest Job First) provavelmente é o ideal, fornecendo a menor média de tempo de espera. A implementação do escalonamento SJF é difícil, porque também é difícil prever a duração do próximo burst de CPU. O algoritmo SJF é um caso especial do algoritmo geral de escalonamento por prioridade, que simplesmente aloca a CPU ao processo de mais alta prioridade. Tanto o escalonamento por prioridade quanto o SJF podem sofrer de starvation. O envelhecimento é uma técnica para impedir a starvation. O escalonamento Round-Robin (RR) é mais apropriado para um sistema de tempo compartilhado (interativo). O escalonamento RR aloca a CPU ao primeiro processo da fila de prontos para q unidades de tempo, onde q é o quantum de tempo. Depois de q unidades de tempo, se o processo não tiver abandonado a CPU, ele é preemptado, e o processo é colocado no final da fila de prontos (ready queue). O problema principal é a seleção do quantum de tempo. Se o quantum for muito grande, o escalonamento RR se degenera para o escalonamento FCFS; se for muito pequeno, o custo adicional do escalonamento, na forma de tempo para troca de contexto, se torna excessivo. O algoritmo FCFS é não preemptivo; o algoritmo RR é preemptivo. Os algoritmos SJF e de prioridade podem ser preemptivos ou não. Os algoritmos multilevel queue permitem a diferentes algoritmos serem utilizados para diversas classes de processos. O mais comum é uma fila interativa de primeiro plano, que utiliza o escalonamento RR, e a fila batch do segundo plano, que utiliza o escalonamento FCFS. A multilevel feedbak-queue permite aos processos mudarem de uma fila para outra. Muitos sistemas de computador contemporâneos admitem vários processadores; cada processador realiza seu escalonamento de forma independente. Em geral, existe uma fila de processos (ou threads), todos disponíveis para execução. Cada processador toma uma decisão de escalonamento e seleciona a partir dessa fila. Os sistemas operacionais que admitem threads no nível do kernel precisam escalonar threads e não processos para serem executados. Isso acontece com o Solaris e o Windows XP, onde os dois sistemas escalonam threads usando algoritmos de escalonamento preemptivos, baseados em prioridade, incluindo o suporte para threads em tempo real. O escalonador de processos do Linux também usa um algoritmo baseado em prioridade com suporte de tempo real. Os algoritmos de escalonamento para esses três sistemas operacionais normalmente favorecem os processos interativos em detrimento dos processos batch e CPUbound. [4]
A JVM utiliza um algoritmo de escalonamento de thread baseada em prioridade, que favorece threads com maior prioridade. A especificação não indica se a JVM deve repartir o tempo das threads; isso fica a cargo da implementação específica da JVM. A grande variedade de algoritmos de escalonamento exige que tenhamos métodos para selecionar entre os algoritmos. Os métodos analíticos utilizam a análise matemática para determinar o desempenho de um algoritmo. Os métodos por simulação determinam o desempenho imitando o algoritmo de escalonamento em uma amostra representativa de processos e calculando o desempenho resultante. [5]
Deadlocks Um estado de deadlock ocorre quando dois ou mais processos estão esperando indefinidamente por um evento que só pode ser causado por um dos processos esperando. Em especial, existem três métodos para lidar com os deadlocks: Usar algum protocolo para prevenir ou evitar deadlocks, garantindo que o sistema nunca entrará em um estado de deadlock. Permitir que o sistema entre no estado de deadlock, detectá-lo e depois recuperar. Ignorar o problema e fingir que os deadlocks nunca ocorrem no sistema. A terceira solução é utilizada pela maioria dos sistemas operacionais, incluindo UNIX e Windows, bem como a JVM. Um deadlock só pode ocorrer se quatro condições necessárias forem satisfeitas simultaneamente no sistema: exclusão mútua, manter e esperar, não preempção e espera circular. Para prevenir deadlocks, podemos garantir que pelo menos uma das condições necessárias nunca seja satisfeita. Um método para evitar deadlocks, menos rigoroso do que os algoritmos de prevenção, exige que o sistema operacional tenha informações a priori sobre como cada processo utilizará os recursos. Usando essas informações, podemos definir um algoritmo para evitar deadlock. Se um sistema não empregar um protocolo para garantir que os deadlocks nunca ocorrerão, então um esquema de detecção e recuperação terá de ser empregado. Um algoritmo de detecção de deadlock precisa ser invocado para determinar se ocorreu um deadlock. Se um deadlock for detectado, o sistema terá de se recuperar terminando alguns de seus processos em deadlock ou apropriando-se dos recursos de alguns dos processos em deadlock. Onde a preempção for usada para cuidar dos deadlocks, três questões precisam ser focalizadas: seleção de uma vítima, reversão e starvation. Em um sistema que seleciona vítimas para efetuar o rollback principalmente com base nos fatores de custo, a starvation poderá ocorrer, e o processo selecionado nunca completa sua tarefa designada. Finalmente, os pesquisadores argumentaram que nenhuma das técnicas básicas isoladamente é apropriada para o espectro inteiro de problemas de alocação de recurso nos sistemas operacionais. As técnicas básicas podem ser combinadas, permitindo a seleção de uma técnica ideal para cada classe de recursos em um sistema. [6]