Sistemas Operacionais

CAPÍTULO 6 - THREADS

6.1. INTRODUÇÃO

Até o final da década de 1970, sistemas operacionais, como Tops-10 (DEC), MVS (IBM) e Unix (Bell Labs), suportavam apenas processos com um único thread (monothread), ou seja, um processo com apenas um único programa fazendo parte do seu contexto. Em 1979, durante o desenvolvimento do sistema operacional Toth, foi introduzido o conceito de processos lightweight (peso leve), onde o espaço de endereçamento de um processo era compartilhado por vários programas. Apesar do conceito revolucionário, a idéia não foi utilizada comercialmente, e somente em meados de 1980, com o desenvolvimento do sistema operacional Mach na Universidade de Carnegie Mellon, ficou clara a separação entre o conceito de processo e thread.

A partir do conceito de múltiplos threads (multithread) é possível projetar e implementar aplicações concorrentes de forma eficiente, pois um processo pode ter partes diferentes do seu código sendo executadas em paralelo, com um menor overhead do que utilizando múltiplos processos. Como os threads de um mesmo processo compartilham o mesmo espaço de endereçamento, a comunicação entre threads não envolve mecanismos lentos de intercomunicação entre processos, aumentando, conseqüentemente: o desempenho da aplicação.

O desenvolvimento de programas que exploram os benefícios da programação multithread não é simples. A presença do paralelismo introduz um novo conjunto de problemas como a comunicação e sincronização de threads. Existem diferentes modelos para a implementação de threads em um sistema operacional, onde desempenho, flexibilidade e custo devem ser avaliados.

Atualmente, o conceito de multithread pode ser encontrado em diversos sistemas operacionais, como no Sun Solaris e Microsoft Windows 2000. A utilização comercial de sistemas operacionais multithread é crescente em função do aumento de popularidade dos sistemas com múltiplos processadores, do modelo cliente-servidor e dos sistemas distribuídos.

6.2. AMBIENTE MONOTHREAD

Um programa é uma seqüência de instruções, composta por desvios, repetições e chamadas a procedimentos e funções. Em um ambiente monothread, um processo suporta apenas um programa no seu espaço de endereçamento. Neste ambiente, aplicações concorrentes são implementadas apenas com o uso de múltiplos processos dependentes ou subprocessos.

A utilização de processos independentes e subprocessos permite dividir uma aplicação em partes que podem trabalhar de forma concorrente. Um exemplo do uso concorrência pode ser encontrado nas aplicações com interface gráfica, como em software de gerenciamento de e-mails. Neste ambiente, um usuário pode estar lendo suas mensagens antigas, ao mesmo tempo que pode estar enviando e-mails e recebendo novas mensagens. Com o uso de múltiplos processos, cada funcionalidade do software implicaria a criação de um novo processo para atendê-la, aumentando o desempenho da aplicação (Fig. 6.1).

Figura 6.1

O problema neste tipo de implementação é que o uso de processos no desenvolvi mento de aplicações concorrentes demanda consumo de diversos recursos do sistema. Sempre que um novo processo é criado, o sistema deve alocar recursos para cada processo, consumindo tempo de processador neste trabalho. No caso do término do processo, o sistema dispensa tempo para desalocar recursos previamente alocados.

Outro problema a ser considerado é quanto ao compartilhamento do espaço de endereçamento. Como cada processo possui seu próprio espaço de endereçamento, a comunicação entre processos toma-se difícil e lenta, pois utiliza mecanismos como pipes, sinais, semáforos, memória compartilhada ou troca de mensagem. Além disto, o compartilhamento de recursos comuns aos processos concorrentes, como memória e arquivos abertos, não é simples. Na Fig. 6.2 existem três processos monothreads, cada um com seu próprio contexto de hardware, contexto de software e espaço de endereçamento.

Figura 6.2

São exemplos de sistemas monothread o Microsoft MS-DOS e as primeiras versões do MS-Windows. Mesmo em ambientes multiprogramáveis e multiusuário, encontramos exemplos de implementações monothread, como nas versões mais antigas dos sistemas Digital VAX/VMS e Unix.

6.3. AMBIENTE MULTITHREAD

Em um ambiente multithread, ou seja, com múltiplos threads, não existe a idéia de programas associados a processos, mas, sim, a threads. O processo, neste ambiente, tem pelo menos um thread de execução, mas pode compartilhar o seu espaço de endereçamento com inúmeros outros threads. Na Fig. 6.3 existe apenas um processo com três threads de execução compartilhando o mesmo espaço de endereçamento.

Figura 6.3

De forma simplificada, um thread pode ser definido como uma sub-rotina de um programa que pode ser executada de forma assíncrona, ou seja, executada paralelamente ao programa chamador. O programador deve especificar os threads, associando-os às sub-rotinas assíncronas. Desta forma, um ambiente multithread possibilita a execução concorrente de sub-rotinas dentro de um mesmo processo.

Na Fig. 6.4 existe um programa principal que realiza a chamada de duas sub-rotinas assíncronas (Sub_1 e Sub_2). Inicialmente, o processo é criado apenas com o Thread_0 para a execução do programa principal. Quando o programa principal chama as sub-rotinas Sub_1 e Sub_2, são criados os Thread_1 e Thread_2, respectivamente, e executados independentemente do programa principal. Neste processo, os três threads são executados concorrentemente.

No ambiente multithread, cada processo pode responder a várias solicitações concorrentemente ou mesmo simultaneamente, caso haja mais de um processador. A grande vantagem no uso de threads é a possibilidade de minimizar a alocação de recursos do sistema, além de diminuir o overhead na criação, troca e eliminação de processos.

Threads compartilham o processador da mesma maneira que processos e passam peIas mesmas mudanças de estado (execução, espera e pronto). Por exemplo, enquanto um thread espera por uma operação de E/S, outro thread pode ser executado. Para permitir a troca de contexto entre os diversos threads, cada thread possui seu próprio contexto de hardware, com o conteúdo dos registradores gerais, PC e SP. Quando um thread está sendo executado, seu contexto