Arquitetura de Sistemas Operacionais

At o final da dcada de 1970, sistemas operacionais, como Unix (Bell Labs), suportavam apenas processos com um nico thread (monothread). Em 1979, durante o desenvolvimento do sistema operacional Toth, foi introduzido o conceito de processos lightweight (peso leve), onde o espao de

endereamento de um processo era compartilhado por vrios programas. Apesar do conceito revolucionrio, a idia no foi utilizada comercialmente, e somente em meados de 1980, com o desenvolvimento do sistema operacional Mach, ficou clara a separao entre o conceito de processo e thread. A partir do conceito de mltiplos threads (multithread) possvel projetar e implementar aplicaes concorrentes de forma eficiente, pois um processo pode ter partes diferentes do seu cdigo sendo executadas em paralelo, com um menor overhead do que utilizando mltiplos processos.

Ambiente Monothread Em um ambiente monothread,um processo suporta apenas um programa no seu espao de endereamento. Neste ambiente, aplicaes concorrentes so implementadas apenas com o uso de mltiplos processos independentes ou subprocessos. Um exemplo do uso de concorrncia pode ser encontrado nas aplicaes com interface grfica, como em um Software de gerenciamento de e-mails. O problema neste tipo de implementao que o uso de processos no desenvolvimento de aplicaes concorrentes demanda consumo de diversos recursos do sistema. Exemplos: Microsoft MS-DOS e as primeiras verses do MSWindows. Verses mais antigas dos sistemas Digital VAX/VMS e Unix.

Ambiente Multithread Em um ambiente multithread, no existe a idia de programas associados a processos, mas, sim, a threads. O processo, neste ambiente, tem pelo menos um thread de execuo, mas pode compartilhar o seu espao de endereamento com inmeros outros threads.

Threads so implementados internamente atravs de uma estrutura de dados denominada bloco de controle do TCB. Em ambientes monothread, o processo ao mesmo tempo a unidade de alocao de recursos e a unidade de escalonamento. Em um ambiente multithread, a unidade de alocao de recursos o processo, onde todos os seus threads compartilham o espao de endereamento, descritores de arquivos e dispositivos de E/S. A grande diferena entre aplicaes monothread e multithread est no uso do espao de endereamento. Como threads de um mesmo processo compartilham o mesmo espao de endereamento, no existe qualquer proteo no acesso memria, permitindo que um thread possa alterar facilmente dados de outros. Em ambientes cliente-servidor. threads so essenciais para solicitaes de servios remotos. Em um ambiente monothread, se uma aplicao solicita um servio remoto, ela pode ficar esperando indefinidamente, enquanto aguarda pelo resultado. Em um ambiente multithread. um thread pode solicitar o servio remoto, enquanto a aplicao pode continuar realizando outras atividades. O conjunto de rotinas disponveis para que uma aplicao utilize as facilidades dos threads chamado de pacote de threads.

THREADS EM MODO USURIO So implementados pela aplicao e no pelo sistema operacional. Para isso, deve existir uma biblioteca de rotinas que possibilite aplicao realizar tarefas como criao/eliminao de threads, troca de mensagens entre threads e uma poltica de escalonamento. A vantagem deste modelo a possibilidade de implementar aplicaes multithreads mesmo em sistemas operacionais que no suportam threads. Utilizando a biblioteca, mltiplos threads podem ser criados, compartilhando o mesmo espao de endereamento do processo. So rpidos e eficientes por dispensarem acessos ao kemel do sistema operacional, evitando assim a mudana de modo de acesso (usurio-kemel-usurio). Talvez um dos maiores problemas na sua implementao seja o tratamento individual de sinais. Os sinais de temporizao devem ser interceptados, para que se possa interromper o thread em execuo e realizar a troca de contexto.

THREADS EM MODO KERNEL Threads em modo kernel (TMK) so implementados diretamente pelo ncleo do sistema operacional, atravs de chamadas a rotinas do sistema que oferecem todas as funes de gerenciamento e sincronizao. O grande problema para pacotes em modo kernel o seu baixo desempenho.

THREADS EM MODO HBRIDO A arquitetura de trhreads em modo hbrido combina as vantagens de threads implementados em modo usurio (TMU) e threads em modo kemel (TMK). Um processo pode ter vrios TMK e, por sua vez, um TMK pode ter vrios TMU. O ncleo do sistema reconhece os TMK e pode escalon-los individualmente. Um TMU pode ser executado em um TMK, em um determinado momento, e no instante seguinte ser executado em outro. O modo hbrido, apesar da maior flexibilidade, apresenta problemas herdados de ambas as implementaes.

SCHEDULER ACTIVATIONS (organizador ativaes) Este pacote combina o melhor das duas arquiteturas, mas em vez de dividir os threads em modo usurio entre os de modo kernel, o ncleo do sistema troca informaes com a biblioteca de threads utilizando uma estrutura de dados chamada scheduler activations (organizador de ativao). A maneira de alcanar um melhor desempenho evitar as mudanas de modos de acesso desnecessrias (usurio-kernel-usurio). Cada camada implementa seu escalonamento de forma independente, porm trocando informaes quando necessrio.

Modelos de Programao O desenvolvimento de aplicaes multithread no simples, exigindo que a comunicao e o compartilhamento de recursos entre os diversos threads seja feto de forma sincronizada para evitar problemas de inconsistncias e deadlock. Um fator importante em aplicaes multithread o nmero total de threads e a forma como so criados e eliminados. Se uma aplicao cria um nmero

excessivo de threads, poder ocorrer um overhead no sistema, ocasionando uma queda de desempenho. Para obter os benefcios do uso de threads, uma aplicao deve permitir que partes diferentes do seu cdigo sejam executadas em paralelo de forma independente. Sistemas gerenciadores de banco de dados (SGBDs), servidores de arquivos ou impresso so exemplos onde o uso de mltiplos threads proporciona grandes vantagens e benefcios.