Ambiente Monothread

THREAD

1 Introdução:

Até o final dos anos 70, os SOs suportavam processos com apenas um thread (monothread), ou seja, um processo com apenas um programa fazendo parte de seu contexto. Em 1979, introduziu-se o conceito de processos “ligthweight” (peso leve), onde o espaço de endereçamento de um processo era compartilhado por vários programas. Porém, esta idéia não foi utilizada comercialmente, e apenas na metade da década de 80, com o SO Mach, ficou clara a separação entre os conceitos de processo e thread.

Com o conceito de múltiplos threads (multithread), pode-se projetar aplicações concorrentes de forma eficiente, pois um processo pode ter diferentes partes de seu código sendo executadas em paralelo. 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 assim o desempenho da comunicaçã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 SO, onde desempenho, flexibilidade e custos devem ser avaliados.

Atualmente, o conceito de multithread pode ser encontrado em sistemas como Sun Solaris e Windows 2000. A utilização comercial de sistemas multithreads tem crescido devido ao aumento de popularidade de sistemas com multiprocessadores, do modelo cliente-servidor w dos sistemas distribuídos.

2 Ambiente Monothread:

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

O uso de processos independentes e subprocessos permite dividir uma aplicação em partes que podem trabalhar de forma concorrente. Por exemplo, um usuário pode estar lendo seus e-mails antigos, ao mesmo tempo em que estaria enviando e recebendo e-mails atuais. Co o uso de múltiplos processos, cada funcionalidade do software implicaria na criação de um novo processo para atendê-lo, aumentando o desempenho da aplicação (Figura 6.1).

Um problema é que o uso de processos no desenvolvimento 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 torna-se difícil e lenta, pois utiliza mecanismos como pipes, sinais, semáforos, memória compartilhada ou troca de mensagem. Além disso, o compartilhamento de recursos comuns aos processos concorrentes, como memória e arquivos abertos, não é simples. Na Figura 6.2 existem três processos monothread, cada um com seu próprio contexto de hardware, de software e espaço de endereçamento.

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

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 em execução, mas pode compartilhar o seu espaço de endereçamento com inúmeros outros threads. Na Figura 6.3 existe apenas um processo com três threads de execução compartilhando o mesmo espaço de endereçamento.

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. Assim, um ambiente multithread possibilita a execução concorrente de sub-rotinas dentro de um mesmo processo.

Na Figura 6.4 existe um programa principal que realiza a chamada de suas 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 duas sub-rotinas, são criados os Thread_1 e Thread_2, e executados independentemente do programa principal. Neste processo, os três threads são executados concorrentemente.

No ambiente multithread, cada processo pode responder a varias 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, alem de diminuir o overhead na criação, troca e eliminação de processos.

Threads compartilham o processador da mesma maneira que processos e passam pelas 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 um 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 hardware está armazenado nos registradores do processador. No momento em que o thread perde a utilização do processador, as informações são atualizadas no seu contexto de hardware.

Dentro de um mesmo processo, threads compartilham o mesmo contexto de software e espaço de endereçamento com os demais threads, porém cada thread possui seu contexto de hardware individual. Threads são implementados internamente através de uma estrutura de dados denominada bloco de controle do thread (Thread Control Block –