Instituto de Matemtica da UFRJ/NCE Depto de Cincia da Computao Mestrado em Informtica Lab.

Sistemas Operacionais II Professor Oswaldo Vernet

Multithread

Tema da monografia: Multithread Autor: Luiz Paulo Maia lpmaia@training.com.br Data: 18/05/98

Multithread ndice
1. Introduo 2. Processos 3. Threads 3.1 Ambiente Monothread 3.2 Ambiente Multithread 3.3 Vantagens 4. Arquitetura e Implementao 4.1 Threads em Modo Usurio 4.2 Threads em Modo Kernel 4.3 Threads em Modo Hbrido 4.4 Scheduler Activations 4.5 Processadores Multithread 5. Pthreads 5.1 Arquitetura 5.2 Sincronizao 6. Modelos de Programao 6.1 Modelo de Grupo de Trabalho 6.2 Modelo Mestre-Escravo 6.3 Modelo de Pipeline Referncia

1. Introduo
Tipicamente, os sistemas operacionais oferecem suporte a processos para o desenvolvimento de aplicaes concorrentes. A utilizao comercial de sistemas operacionais e aplicaes multithread recente, mas sua implementao est crescendo devido ao aumento de popularidade dos sistemas com mltiplos processadores, do modelo cliente-servidor e dos sistemas distribudos. Com threads, um processo pode ter diferentes partes do seu cdigo sendo executadas concorrentemente ou simultaneamente, com muito menos overhead que utilizando mltiplos (sub)processos. Como os threads de um mesmo processo compartilham o mesmo espao de endereo, a comunicao dos threads no envolve mecanismos lentos de intercomunicao entre processos. Basicamente, multithreading uma tcnica de programao concorrente, que permite projetar e implementar aplicaes paralelas de forma eficiente. O desenvolvimento de programas que exploram os benefcios da programao multithread no simples. A presena do paralelismo introduz um novo conjunto de problemas, como a comunicao e sincronizao de threads. Existem diferentes modelos para a implementao de threads em um sistema operacional, onde desempenho, flexibilidade e custo devem ser avaliados atentamente. Alm dos modelos tradicionais, com nfase especial ao padro Pthreads, apreciaremos arquiteturas novas e pouco difundidas. Este trabalho pretende esclarecer o que vem a ser threads, sua utilizao, vantagens, implementao e cuidados na programao concorrente. Antes porm, devemos apresentar o conceito de processo, que est intimamente relacionado a threads.

2. Processos
O conceito de processo surgiu nos anos 60, sendo a base da multiprogramao e dos sistemas de tempo compartilhado (time-sharing). O processo pode ser entendido como um programa em execuo, s que seu conceito mais abrangente. Este conceito torna-se mais claro quando pensamos de que forma os sistemas multiprogramveis (multitarefa) atendem os diversos usurios (tarefas) e mantm informaes a respeito dos vrios programas que esto sendo executados concorrentemente. Como sabemos, um sistema multiprogramvel simula um ambiente de monoprogramao para cada usurio, isto , cada usurio do sistema tem a impresso de possuir o processador exclusivamente para ele. Nesses sistemas, o processador executa a tarefa de um usurio durante um intervalo de tempo (time-slice) e, no instante seguinte, est processando outra tarefa. A cada troca, necessrio que o sistema preserve todas as informaes da tarefa que foi interrompida, para quando voltar a ser executada no lhe faltar nenhuma informao para a continuao do processamento. A estrutura responsvel pela manuteno de todas as informaes necessrias execuo de um programa, como contedo de registradores e espao de memria, chama-se processo. O conceito de processo pode ser definido como sendo o ambiente onde se executa um programa. Um mesmo programa pode produzir resultados diferentes, em funo do processo no qual ele executado. Por exemplo, se um programa necessitar abrir cinco arquivos simultaneamente, e o processo onde ser executado s permitir que se abram quatro, o programa ser interrompido durante a sua execuo. O processo pode ser dividido em trs elementos bsicos: contexto de hardware, contexto de software e espao de endereamento, que juntos mantm todas as informaes necessrias execuo do programa (Fig. 1).

Fig. 1 Processo Contexto de hardware constitui-se, basicamente, no contedo de registradores: program counter (PC), stack pointer (SP) e bits de estado. Quando um processo est em execuo, o contexto de hardware est armazenado nos registradores do processador. No momento em que o processo perde a utilizao da UCP, o sistema salva suas informaes. Contexto de software especifica caractersticas do processo que vo influir na execuo de um programa, como, por exemplo, o nmero mximo de arquivos abertos simultaneamente ou o tamanho do buffer para operaes de E/S. Essas caractersticas so determinadas no momento da criao do processo, mas algumas podem ser alteradas durante sua existncia. O contexto de software define basicamente trs grupos de informaes de um processo: sua identificao, suas quotas e seus privilgios. Espao de endereamento a rea de memria do processo onde o programa ser executado, alm do espao para os dados utilizados por ele. Cada processo possui seu prprio espao de endereamento, que deve ser protegido do acesso dos demais processos.

3. Threads
At o final da dcada de 70, os sistemas operacionais mais populares, como Tops-10 (DEC), MVS (IBM) e Unix (Bell), suportavam apenas processos, sem threads. 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 poderia ser compartilhado por vrios programas. Apesar do conceito revolucionrio, a idia no foi aceita comercialmente e somente em meados de 1980, com o desenvolvimento do sistema operacional Mach, na Universidade de Carnegie Mellon, ficou clara a separao entre o conceito de processo e threads. Atualmente, o mesmo conceito pode ser encontrado em sistemas operacionais, como OS/2 (IBM), Solaris (Sun) e Windows NT (Microsoft), dentre outros. 3.1 Ambiente Monothread Um programa (tarefa) uma seqncia de instrues, composto por desvios, repeties (iteraes) e chamadas de procedimentos e/ou funes. Em um ambiente de programao monothread, um processo suporta apenas um programa no seu espao de endereamento e apenas uma instruo do programa executada. Caso seja necessrio criar-se aplicaes concorrentes e paralelas so implementados mltiplos processos independentes e/ou subprocessos. A utilizao de (sub)processos independentes permite dividir uma aplicao em partes que podem trabalhar de forma concorrente. Por exemplo, suponha que um processo seja responsvel pelo acesso a um banco de dados e existam vrios usurios solicitando consultas sobre esta base. Caso um usurio solicite um relatrio impresso de todos os registros, os 4

demais usurios tero de aguardar at que a operao termine. Com o uso de mltiplos processos, cada solicitao implicaria a criao de um novo processo para atend-la, aumentando o throughput da aplicao. Existem, porm, dois problemas neste tipo de abordagem. O uso de (sub)processos no desenvolvimento de aplicaes concorrentes demanda consumo de diversos recursos do sistema. Sempre que um novo processo criado, o sistema deve alocar recursos (contexto de hardware, contexto de software e espao de endereamento) para cada processo, alm de consumir tempo de UCP neste trabalho. No caso do trmino do processo, o sistema dispensa tempo para desalocar recursos previamente alocados. Na Fig. 2 existem trs processos, cada um com seu prprio contexto de hardware, contexto de software e espao de endereamento.

Fig. 2 Ambiente monothread Como cada processo possui seu prprio espao de endereamento, a comunicao entre os (sub)processos torna-se difcil e lenta, pois utiliza mecanismos tradicionais como pipes, sinais, semforos, memria compartilhada ou troca de mensagem. Alm disto, o compartilhamento de recursos comuns aos (sub)processos concorrentes, como memria e arquivos abertos, no simples. 3.2 Ambiente Multithread Na tentativa de diminuir o tempo gasto na criao/eliminao de (sub)processos, bem como economizar recursos do sistema como um todo, foi introduzido o conceito de thread. Em um ambiente de mltiplos threads (multithread), no necessrio haver vrios processos para se implementar aplicaes concorrentes. No ambiente multithread, cada processo pode responder a vrias solicitaes concorrentemente ou mesmo simultaneamente, se houver mais de um processador. Na Fig. 3 existe apenas um processo com trs threads de execuo, cada um com seu program counter (PC).

Fig. 3 Ambiente Multithread Em um ambiente multithread, no existe a idia de um programa, mas de threads (linhas). O processo, neste ambiente, tem pelo menos um thread de execuo, podendo compartilhar o seu espao de endereamento com inmeros threads, que podem ser executados de forma concorrente e/ou simultnea, no caso de mltiplos processadores. 5

Threads compartilham o processador da mesma maneira que um processo. Por exemplo, enquanto um thread espera por uma operao de E/S, outro thread pode ser executado. Cada thread possui seu prprio conjunto de registradores (contexto de hardware), porm compartilha o mesmo espao de endereamento com os demais threads do processo. Os threads de um mesmo processo compartilham, alm do espao de endereamento, outros atributos, como temporizadores e arquivos, de forma natural e eficiente (Fig. 4).

Fig. 4 Compartilhamento de recursos Quando um thread est sendo executado, o contexto de hardware est armazenado nos registradores do processador. No momento em que um thread perde a utilizao do processador, o sistema salva suas informaes. Threads passam pelos mesmos estados que um processo, ou seja, execuo, espera e pronto. A grande diferena entre subprocessos e threads em relao ao espao de endereamento. Enquanto subprocessos possuem, cada um, espaos independentes e protegidos, threads compartilham o mesmo espao de endereamento do processo, sem nenhuma proteo, permitindo que um thread possa alterar dados de outro thread. Apesar dessa possibilidade, threads so desenvolvidos para trabalhar de forma cooperativa, voltados para desempenhar uma tarefa em conjunto. 3.3 Vantagens Programas concorrentes que utilizam mltiplos threads so mais rpidos do que implementados como mltiplos (sub)processos. Como os threads compartilham os recursos do processo, as operaes de criao, troca de contexto e eliminao dos threads geram um ganho de desempenho. Como todos os threads em um processo compartilham o mesmo espao de endereamento, a comunicao entre os threads pode ser feita utilizando o compartilhamento de memria (shared memory) de forma rpida e eficiente. De forma 6

semelhante ao compartilhamento de memria, os threads dentro do mesmo processo podem compartilhar facilmente outros recursos, como descritores de arquivos, temporizadores (timers), sinais, atributos de segurana etc. A utilizao dos recursos de hardware, como UCP, discos e perifricos, pode ser feita de forma concorrente pelos diversos threads, significando uma melhor utilizao dos recursos computacionais disponveis. Em algumas aplicaes, a utilizao de threads pode melhorar o desempenho da aplicao apenas executando tarefas secundrias (background), enquanto operaes, como entrada e sada, esto sendo processadas. Aplicaes como editores de texto, planilhas, aplicativos grficos e processadores de imagens so especialmente beneficiados quando desenvolvidos com base em threads. As vantagens oferecidas em ambientes com mltiplos processadores podem ser aproveitadas em aplicaes multithread, dispensando qualquer preocupao por parte dos desenvolvedores. O escalonamento realizado com base na prioridade de cada thread, sendo selecionado aquele com maior prioridade. Dessa forma, o programador pode determinar nveis de prioridade das threads em funo da importncia de cada uma. Aplicaes que podem ser naturalmente paralelizadas, como ordenao e pesquisa, obtm ganhos de desempenho por serem executadas em mltiplos processadores simultaneamente. Em ambientes distribudos, 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 teis. J para o processo que atende a solicitao, mltiplos threads permitem que diversos pedidos sejam atendidos concorrentemente e/ou simultaneamente. No apenas aplicaes tradicionais podem fazer uso dos benefcios do multithreading. O ncleo do sistema operacional tambm. Quando o kernel multithread possvel atender a vrias solicitaes, como, por exemplo, em device drivers. Neste caso, mecanismos de sincronizao devem ser utilizados para proteger as estruturas de dados internas do ncleo.

4. Arquitetura e Implementao
O conjunto de chamadas (primitivas) disponveis para que uma aplicao utilize as facilidades dos threads chamado de pacote de threads (threads package). Existem diferentes abordagens na implementao deste pacote em um sistema operacional, o que influenciar o desempenho, concorrncia e modularidade das aplicaes multithread. Threads podem ser oferecidos pelo prprio ncleo do sistema operacional (thread em modo kernel), por uma biblioteca de rotinas fora do ncleo do sistema (thread em modo usurio), uma combinao de ambos (hbrido), seguir o novo modelo de scheduler activations ou a novssima arquitetura de processadores multithread. A tabela abaixo sumariza as diversas arquiteturas para diferentes sistemas operacionais. Sistemas Distributed Computing Environment (DCE) Xerox's Portable Common Runtime (PCR) DEC OpenVMS verso 6.* Windows NT Digital Unix DEC OpenVMS verso 7.* IBM OS/2 Sun Solaris verso 2.* University of Washington FastThreads Tera MTA 4.1 Threads em Modo Usurio Threads em modo usurio so implementas por chamadas a uma biblioteca de rotinas que so linkadas e carregadas em tempo de execuo (run-time) no mesmo espao de endereamento do processo e executadas em modo usurio (fig. 5). O 7 Arquitetura Modo usurio Modo usurio Modo usurio Modo kernel Modo kernel Modo kernel Modo kernel Modo hbrido Scheduler activations Processador multithread

sistema operacional no sabe da existncia de mltiplos threads, sendo responsabilidade da biblioteca gerenciar e sincronizar os diversos threads existentes.

Fig. 5 Threads em modo usurio A primeira vantagem deste modelo a possibilidade de sistema operacional que no suporta threads, implementar aplicaes multithreads. Utilizando a biblioteca, mltiplos threads poder ser utilizados, compartilhando o mesmo espao de endereamento do processo e outros recursos. Threads em modo usurio so rpidos e eficientes, por dispensar acesso ao kernel do sistema para a criao, eliminao, sincronizao e troca de contexto das threads. A biblioteca oferece todo o suporte necessrio em modo usurio, sem a necessidade de chamadas ao sistema (system calls). O sistema operacional desconhece a existncia dos threads, sendo responsabilidade da biblioteca particionar o tempo de UCP do processo (time-slice) entre os diversos threads existentes. Como cada aplicao possui sua cpia da biblioteca, possvel implementar uma poltica de escalonamento diferente, em funo da sua necessidade. Apesar das vantagens, threads em modo usurios so difceis de implementar. Um grande problema surge quando um thread utiliza uma chamada ao sistema que a coloca em estado de espera (chamada bloqueante ou sncrona), como, por exemplo, uma operao de entrada/sada. Neste caso, como o sistema operacional encara o processo com apenas um thread, o sistema coloca todo o processo em estado de espera, mesmo havendo outros threads prontos para a execuo. Para contornar o problema das chamadas sncronas, a biblioteca tem que implementar todas as chamadas que possam causar o bloqueio de um thread. Sempre que uma chamada ao sistema realizada, a biblioteca verifica a possibilidade de bloqueios e intervm, utilizando uma chamada assncrona prpria. Todo este controle transparente para o usurio e para o sistema operacional. Outro problema do pacote em modo usurio est no compartilhamento de variveis da biblioteca multithread sem a devida sincronizao. Bibliotecas que apresentam este tipo de problema so ditas no reentrante ou thread-safe (segura). Para contorna-lo, a biblioteca deve fornecer para cada thread um conjunto individual de variveis ou o programador deve intervir para a garantir a integridade das variveis. No apenas a biblioteca multithread deve ser thread-safe, mas tambm todas as bibliotecas oferecidas pelo sistema operacional utilizadas pela aplicao. Talvez um dos maiores problemas na implementao de threads em modo usurio, seja o tratamento de sinais por cada thread individualmente. Como o sistema reconhece apenas processos e no threads, os sinais enviados para um processo devem ser reconhecidos pela biblioteca e encaminhado ao thread correspondente. Um problema crtico no tratamento de sinais o recebimento de interrupes de clock, fundamental para a implementao do time-slice. Logo, para oferecer escalonamento preemptivo, a biblioteca deve receber sinais de temporizao, interromper o thread em execuo e realizar a troca de contexto. Outro grande problema relacionado ao escalonamento a incapacidade de mltiplos threads em um processo serem executados por processadores diferentes simultaneamente, em ambientes com mltiplos processadores. Esta restrio limita drasticamente o grau de paralelismo da aplicao, j que os threads de um mesmo processo podem ser executados em somente um processador de cada vez. 8

4.2 Threads em Modo Kernel Threads em modo kernel so implementadas diretamente pelo ncleo do sistema, por chamadas ao sistema (system calls) que oferecem todas as funes de gerenciamento e sincronizao (Fig. 6). O sistema operacional (escalonador) sabe da existncia de cada thread e pode escalona-los individualmente. No caso de mltiplos processadores, os threads de um mesmo processo podem ser executados simultaneamente.

Fig. 6 Threads em modo kernel Os problemas apresentados para a implementao de pacotes em modo usurio no so encontrados neste modelo, como compartilhamento de variveis, tratamento de sinais, chamadas sncronas, escalonamento em mltiplos processadores etc. O grande problema para pacotes em modo kernel o seu desempenho, sendo da ordem de dez vezes mais lento que o modo usurio. Enquanto que pacotes em modo usurio todo tratamento feito sem a ajuda do sistema operacional, ou seja, sem a mudana do modo de acesso (usurio-kernel-usurio), pacotes em modo kernel utilizam chamadas ao sistema e conseqente mudana de modo de acesso. 4.3 Threads em Modo Hbrido Nesta arquitetura existe a idia de combinar as vantagens de threads implementados em modo usurio e modo kernel. Para facilitar a explicao deste modelo, chamaremos os threads em modo kernel de TMKs e os de modo usurio de TMUs. Um processo pode ter vrios TMKs e, por sua vez, um TMK pode ter vrios TMUs. O ncleo do sistema reconhece os TMKs 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.

Fig. 7 Threads em modo hbrido

O programador desenvolve a aplicao em termos de TMUs e especifica quantos TMKs esto associados ao processo. Os TMU so mapeados em TMK enquanto o processo est sendo executado. O programador pode utilizar apenas TMKs, TMUs ou uma combinao de ambos, como mostra a Fig. 7. O pacote hbrido, apesar da maior flexibilidade, tambm apresenta problemas herdados de ambas as implementaes. Por exemplo, quando um TMK realiza uma chamada bloqueante, todos os TMUs so colocados no estado de espera. TMUs que desejam utilizar vrios processadores devem utilizar diferentes TMKs, o que influenciar no desempenho. 4.4 Scheduler Activations Os problemas apresentados no pacote de threads hbrido existem devido a falta de comunicao entre os threads em modo usurio e modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em modo kernel com o desempenho e flexibilidade do modo usurio. Introduzido no incio da dcada de 90, na Universidade de Washington, este pacote combina o melhor do dois mundos, mas ao contrrio de multiplexar 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 activation (Fig. 8). A maneira de alcanar um melhor desempenho evitar a mudanas de acessos (usurio-kernel-usurio) desnecessrias. Caso um thread utilize uma chamada ao sistema que o coloque no estado de espera, no necessrio que o kernel seja ativado. Basta que a prpria biblioteca em modo usurio possa escalonar outro thread. Isto possvel porque a biblioteca em modo usurio e o kernel se comunicam e trabalham de forma cooperativa. Cada camada implementa seu escalonamento de forma independente, porm trocando informaes quando necessrio.

Fig. 8 Scheduler activations 4.5 Processadores Multithread O conceito de thread reduziu significativamente o tempo gasto na troca de contexto entre processos, mas para algumas aplicaes este tempo continua alto. Para reduzir o tempo de troca e, assim, aumentar a concorrncia, uma nova arquitetura de processadores est sendo oferecida. Em uma arquitetura de processador multithread, a troca de contexto dos threads feita por hardware, diretamente no processador, quase eliminado a latncia da troca de contexto. Este tipo de arquitetura comeou a ser estudada na dcada de 50, mas foi apenas na dcada de 70 que o primeiro sistema multithread foi comercializado, o Heterogeneous Element Processor (HEP) da Denelcor. Atualmente, o MTA da Tera Computer vem sendo comercializado com base nesta nova tecnologia.

10

Em uma arquitetura multithread, os threads so mapeados em contextos de hardware, que incluem registradores, bits de estado e contador de intrues (PC). Cada contexto representa um thread que pode ser executado, aguardando apenas uma chance de ser executado. Por limitaes de hardware, nem todos os threads estaro mapeados em um contexto de hardware. Apesar da grande melhoria de desempenho, arquiteturas multithread so mais caras e complexas que as arquiteturas tradicionais de alto desempenho.

5. Pthreads
Uma das grandes dificuldades da utilizao de threads em aplicaes em geral foi a ausncia de um padro. Em 1995, o padro POSIX (Portable Operating System Interface) P1003.1c foi aprovado. Com este padro, tambm conhecido como Pthreads, aplicaes comerciais multithread devero tornar-se mais comuns. A tabela abaixo apresenta as principais APIs definidas pelo padro POSIX.1c. Descrio Gerenciamento POSIX Thread API Pthread_create Pthread_exit pthread_join pthread_kill Pthread_t pthread_self Pthread_mutex_init Pthread_mutex_trylock Pthread_mutex_lock Pthread_mutex_unlock Pthread_mutex_destroy Pthread_cond_init Pthread_cond_destroy Pthread_cond_wait Pthread_cond_timedwait Pthread_cond_signal Pthread_cond_broadcast

Excluso mtua

Variveis condicionais

O padro Pthreads largamente encontrado em ambientes Unix, geralmente implementado em aplicaes escritas em Linguagem C. 5.1 Arquitetura O POSIX.1c pode ser implementado apenas em modo usurio, modo kernel ou uma combinao de ambos (hbrido). O padro utiliza a abordagem de orientao a objetos para representar suas propriedades, como tamanho de pilha, poltica de escalonamento e prioridades para os threads. Diversos threads podem ser associados ao mesmo objeto e, caso uma alterao seja feita, todos os threads associados sero afetados. No padro POSIX.1c, threads so criados e eliminados dinamicamente, conforme a necessidade. Alm disto, o padro oferece mecanismos de sincronizao, como semforos, mutexes e variveis condicionais. No ambiente Pthreads, sinais so enviados para o processo, no threads. Para cada thread existe uma mscara de sinais e, quando chega um sinal, o processo deve identificar para qual thread se destina. O tratamento de sinais muito dependente da implementao do pacote em um determinado sistema operacional. O POSIX threads exige que todas as bibliotecas e chamadas ao sistema sejam thread-safe, ou seja, se um fabricante deseja oferecer o pacote, dever reescrever grande parte do sistema para torn-lo compatvel. 5.2 Sincronizao 11

O Pthreads oferece inmeras funes para a sincronizao entre threads. A seguir descrevemos, resumidamente, estes mecanismos: Mutexes

Uma varivel mutex (Mutual Exclusion) permite implementar a excluso mtua, ou seja, o acesso a uma regio crtica feito de forma a impedir os problemas de sincronizao (race conditions). Variveis condicionais

Uma varivel condicional permite associar uma varivel a um evento, que poder ser, por exemplo, um contador alcanando um determinado valor ou um flag sendo ligado/desligado. Em uma aplicao multithread, a utilizao de variveis condicionais permite criar um mecanismo de comunicao entre os diversos threads, que, por sua vez, permite a execuo condicional em torno de eventos (sincronizao). Semforos

Semforos so semelhantes aos mutexes, com a diferena que, enquanto um mutex pode variar seu valor entre zero e um, semforos podem assumir outros valores, permitindo sua utilizao como contadores. Semforos esto disponveis apenas em sistemas que oferecem suporte ao padro POSIX com extenses para tempo-real (POSIX.1b).

6. Modelos de Programao
O desenvolvimento de aplicaes multithread no simples, pois exige que a comunicao e o compartilhamento de recursos entre os diversos threads seja feito de forma sincronizada, para evitar problemas de inconsistncias e deadlock. Alm das dificuldades naturais no desenvolvimento de aplicaes paralelas, existe tambm o problema de sua depurao. Um fator importante em aplicaes multithread o nmero de threads da aplicao e como so criados e eliminados. Se uma aplicao cria um nmero excessivo de threads poder ocorrer um overhead no sistema, gerando uma queda de desempenho. Dependendo da implementao a definio do nmero de threads pode ser dinmica ou esttica. Quando a criao/eliminao dos threads dinmica, estes so criados/eliminados conforme a demanda da aplicao, oferecendo uma grande flexibilidade. J em ambientes estticos, o nmero de threads definido na criao do processo onde a aplicao ser executada, limitando o seu throughput. As aplicaes que obtm ganhos sendo desenvolvidas como mltiplos threads devem obrigatoriamente poder ser divididas em mdulos independes, que possam ser executadas concorrentemente e/ou simultaneamente. Se uma aplicao realiza vrias operaes de E/S e/ou trata eventos assncronas, como acesso rede ou interrupes de hardware ou software, a programao multithread pode aumentar seu desempenho e throughput, mesmo em ambientes com um nico processador. Aplicaes como servidores de banco de dados, servidores de arquivo e impresso so ideais para multithreading, pois lidam com inmeras operaes de E/S e eventos assncronos. Aplicaes tipicamente orientadas ao processador (CPU-bound) e processadas em ambientes com mltiplos processadores, tambm podem obter melhorias de desempenho. Aplicaes que trabalham com matrizes, equaes, ordenaes, pesquisas e processamento de imagens podem obter ganhos significativos com o aumento de paralelismo permitido. Existem maneiras diferentes de dividir e organizar uma aplicao multithread. Dependendo da natureza do problema, podemos escolher basicamente entre trs modelos de programao. 6.1 Modelo de Grupo de Trabalha 12

No modelo de grupo de trabalho (workgroup, peer-to-peer ou workcrew), todos os threads trabalham de forma concorrente para a soluo cooperativa do problema, onde cada thread executa uma tarefa bem especfica. Neste modelo, um thread responsvel por criar todos os demais threads da aplicao, na criao do processo. Pode ocorrer de um thread no poder atender a uma solicitao, por j estar ocupado. Para contornar esta limitao, deve-se manter uma fila de terefas pendentes por thread. O modelo de grupo de trabalho adequado para aplicaes que tm um nmero conhecido de tarefas a serem executadas. Por exemplo, suponha um editor de textos com mltiplos threads, onde um thread responsvel pela entrada de dados pelo teclado, um segundo pela a exibio no monitor e um terceiro pela gravao peridica do texto em um arquivo em disco (Fig. 9).

Fig. 9 Modelo de grupo de trabalho Um outro exemplo muito comum do uso de threads pode ser apreciado em um simples programa que realiza uma cpia de um arquivo e permite o cancelamento da operao. No caso de no utilizarmos a soluo multithread, o programa periodicamente deve testar se a opo de cancelamento foi acionada (polling). J na soluo por thread, podemos imaginar que existe um thread responsvel pela cpia e um outro preocupado apenas com o cancelamento da operao. 6.2 Modelo Mestre-escravo No modelo mestre-escravo (master-slave) ou chefe-trabalhador (boss-worker) existe um thread principal (mestre), responsvel por criar, eliminar e coordenar os threads que efetivamente executaro as tarefas (escravos). O mestre pode criar os threads escravos dinamicamente a cada solicitao ou cria-los previamente (thread-pool) na inicializao do processo. A segunda opo permite alcanar um melhor desempenho, na medida em que elimina o tempo gasto na criao/eliminao dos threads. 13

Este modelo indicado para aplicaes que devem manipular vrias solicitaes concorrentes, como, por exemplo, uma aplicao cliente-servidor. Neste tipo de aplicao, o servidor deve atender a mltiplas solicitaes dos clientes. Neste caso, cada solicitao de um cliente pode ser tratada por uma thread independente criada pelo servidor. Neste modelo, o nmero de threads varivel, dependendo da carga que a aplicao est sofrendo (Fig. 10).

Fig. 10 Modelo mestre-escravo 6.3 Modelo de Pipeline O modelo de pipeline deve ser empregado quando um problema pode ser dividido em vrios threads, por onde os dados ao sair de um thread podem ser processados pelo thread seguinte, como em uma linha de produo. Um exemplo deste modelo pode ser encontrado em linguagens de controle, onde a sada de um comando a entrada para um prximo, que por sua vez gera a entrada para um outro e, assim, de forma sucessiva, como no redirecionamento de entrada/sada. Outro exemplo de aplicao onde o pipeline pode ser til pode ser apreciado em aplicaes para processamento de imagens. Referncias [Byrd_1] [Kleiman_1] [Nichols_1] [Pham_1] [Robbins_1] [Tanenbaun_1] Gregory T. Byrd & Mark A. Holliday. Multithreaded Processor Architectures. IEEE Spectrum, August, 1995. Steve Kleiman, Devang Shah & Bart Smalders. Programming with Threads. SunSoft Press, Prentice-Hall, 1996. Bradford Nichols, Dick Buttar & Jacqueline Firrell. Pthreads Programming. O'Reilly Press, 1996. Thuan Q. Pham & Pankaj K. Gang. Multithreaded Programming with Windows NT, PrenticeHall, 1996 Kay A. Robbins & Steven Robbins. Practical Unix Programming: A Guide to Concurrency, Comunication, and Multithreading. Prentice-Hall, 1996. Andrew Tanenbaum. Distributed Operating Systems. Prentice-Hall, 1995.

14