Introdução aos Processos Leves ( Threads )

Transcrição

1 1 Introdução aos Processos Leves ( Threads ) João Paulo F. W. Kitajima Marco Aurélio de Souza Mendes Departamento de Ciência da Computação Universidade Federal de Minas Gerais Caixa Postal Belo Horizonte, MG tel: (031) /fax: (031) {kitajima, corelio@dcc.ufmg.br Introdução A importância do processamento paralelo na busca por maior poder de computação está atualmente bem definida. O princípio do "trabalho cooperativo" é bastante intuitivo e pode ser diretamente aplicado (1) em novas arquiteturas de computadores, onde vários processadores trabalham simultaneamente na resolução de um problema específico, (2) em novos sistemas operacionais, que suportam processos concorrentes (em multiprogramação e/ou em multiprocessamento), e (3) em novas linguagens de programação, permitindo que soluções sejam expressas de acordo com um paradigma de programação concorrente e/ou paralela. Nas Jornadas de Atualização de Informática de 1995, o primeiro autor aborda o item (3), apresentando elementos de linguagens para programação distribuída (i.e., baseada na troca de mensagens) [KIT95]. Neste texto, os autores abordam o item (2), onde alguns mecanismos do sistema operacional de suporte à concorrência são apresentados, com reflexos, naturalmente, sobre as linguagens de programação disponíveis no sistema em questão. Três exemplos são apresentados: dois sistemas operacionais multithreaded (Solaris e Eindows NT) e uma linguagem atual de programação orientada a objetos, Java, que implementa classes associadas às threads. 1. Gerência de Processos Computadores (isolados, paralelos ou em rede) realizam tarefas. Estas tarefas podem ser de diferentes naturezas: por exemplo, a execução de um programa objeto compilado a partir de um

2 programa fonte em C, a própria compilação deste programa, a própria edição do programa fonte em C, controle de temperatura de uma estufa, e gerência da memória do próprio computador e dos dispositivos de entrada e saída conectados a ele. Além do mais, estas tarefas podem estar em execução todas ao mesmo tempo, seja compartilhando um único processador, e, neste caso, falamos em multiprogramação, seja utilizando vários processadores, considerando assim a ocorrência de multiprocessamento ou, tão simplesmente, de execuções em paralelo. Sistemas Operacionais. Todo sistema computacional, exceto os mais primitivos ou os muito especializados, são dotados de um sistema operacional. Este sistema operacional possui duas funções básicas [TAN92]: 1. apresentar ao usuário do computador (seja um programador de linguagem de alto nível, seja um usuário de aplicativos) uma máquina estendida ou virtual. O sistema operacional funciona então como um intermediário entre as aplicações e o hardware: os detalhes reais do hardware tornamse transparentes para os usuários. Se um sistema operacional com tal função não existisse, um programador precisaria, por exemplo, saber ativar o barramento de controle e de dados de maneira apropriada a fim de realizar uma leitura de uma posição da memória principal e copiar o valor lido para outra posição da memória. Mesmo em linguagem de montagem (assembler), esta operação se resume, em geral, às seguinte instruções: LOAD (X) STORE (Y) % registrador recebe valor da posição X da memória % posição Y da memória recebe valor do registrador Compiladores e linguagens de comandos (ou shells) são outros componentes (não do sistema operacional) que complementam esta função do sistema operacional de esconder detalhes do hardware dos usuários finais dos computadores; 2. gerenciar os recursos de um sistema computacional, sejam recursos de software, sejam recursos de hardware. Por exemplo, a organização dos arquivos em disco, o controle da multiprogramação e controle de utilização da impressora. Sob este aspecto, o sistema operacional é visto como uma entidade de controle [SIL94].

3 3 Um sistema operacional é um programa ou um conjunto de programas que implementam estas duas funções acima. Dentro de cada possibilidade (fornecer uma máquina virtual e gerenciar recursos), as atividades realizadas variam de sistema operacional para sistema operacional. Podemos encontrar sistemas operacionais completos, fornecendo todos os serviços imagináveis aos usuários, e sistemas operacionais menos potentes, onde alguns serviços devem ser realizados pelo próprio usuário. Exemplos de sistemas operacionais são Unix (e suas inúmeras variações), DOS, Windows NT, OS/2, MACH e outros menos conhecidos, como QNX, Amoeba, Chorus, e Helios. É importante observar que, por ser um ou mais programas, um sistema operacional é também composto de um conjunto de tarefas que são executadas pelo processador. Sistema operacional é software, embora algumas de suas funções possam ser implementadas em hardware. A Figura 1 apresenta uma visão modular e hierárquica de um sistema computacional. Usuário 1 Usuário 2 Usuário 3 Usuário N Programas de Aplicação Sistema Operacional Hardware do Computador Figura 1. Uma visão modular e hierárquica de um sistema computacional [SIL94]. Processos. Independente se as tarefas são de usuários típicos, de programadores ou do sistema operacional, elas são executadas pelo processador e são gerenciadas pelo próprio sistema operacional (neste sentido, o sistema operacional se executa utilizando os seus próprios mecanismos de controle). Toda tarefa em execução que envolve um programa objeto (código), dados e um estado é visto pelo sistema operacional como um processo sequencial ou, simplesmente, processo. Informalmente, um processo é um programa em execução [SIL94]. Um processo não é um programa. Um programa é um arquivo armazenado geralmente em um meio magnético ou óptico,

4 escrito em uma linguagem de alto ou baixo nível. Um processo é um programa em execução. Uma receita de bolo é um programa. Fazer o bolo usando a receita é um processo. Processos são abstrações (da atividade da CPU) que são manipuláveis pelo sistema operacional. Um sistema operacional enxerga uma tarefa como um processo. Eventualmente, uma tarefa de um usuário é vista pelo sistema operacional como um conjunto de processos. Por exemplo, um processamento em lote (batch) envolve um job que se pode consistir em: (1) compilar um programa, (2) ligá-lo a outros módulos pré-compilados e (3) executar o programa objeto ligado final. Para o sistema operacional, este job é realizado através de três diferentes processos, um para cada etapa. Antes de entrar em detalhes sobre como processos são implementados, é importante observar que processos são criados por outros processos. Quando um computador é ligado, um programa de boot carrega módulos do sistema operacional que, a partir de sua execução, lançarão outros processos do sistema e suportarão processos de usuários. Qualquer processo, por sua vez, pode lançar novos processos, formando então uma estrutura hierárquica de processos. Processos também possuem estados e podem interagir com outros processos. Além disto, como visto acima, em um dado sistema computacional, podem existir vários processos em execução, normalmente, associados a diferentes usuários de um computador multiprogramado. O escalonador é o módulo do sistema operacional que decide a ordem de execução dos processos, dado que um ou mais processadores estão disponíveis. Processos podem ser preemptáveis, se eles podem ser interrompidos durante a sua execução a fim de que outro processo execute, ou processos podem ser não preemptáveis, se eles não podem ser interrompidos (ou seja, executam do início ao fim ou explicitamente se bloqueiam). Após a interrupção de um processo ou o seu fim, o escalonador deve decidir quem deve executar em seguida. Tomada a decisão, o despachante (em inglês, dispatcher) efetivamente ativa o processo escolhido para execução. Pelo fato de que processos podem interagir com outros processos, processos podem bloquear-se durante esta interação. Por exemplo, um processo, a fim de que possa continuar o seu trabalho, pode aguardar dados oriundos de outro processo. Enquanto espera, o processo está parado, bloqueado. Assim, é possível observar que processos podem estar em diferentes estados. Do discurso acima, três estados são citados: a) um processo em execução (running): é o processo cujas instruções o processador está correntemente executando;

5 5 b) um processo pronto para executar (ready): é o processo que pode ser executado pelo processador, mas não está em execução pois não foi escolhido ainda pelo escalonador; c) um processo bloqueado (blocked): como um processo pronto para executar, um processo bloqueado também está em espera, mas não para ser escolhido pelo escalonador. Ele espera a ocorrência de um outro evento, por exemplo, recepção de dados, a passagem de 5 segundos ou o término de uma operação de entrada e saída (I/O). Quando o evento ocorre, o processo muda de estado, passando de bloqueado para pronto para executar. A Figura 2 apresenta um diagrama de transição dos possíveis estados de um processo. O modelo de processos facilita a compreensão da dinâmica do computador. Uma outra visão possível é aquela baseada em interrupções: nesta abordagem, diferentes interrupções estão ocorrendo no sistema. A cada interrupção ocorrida, uma tarefa deve ser realizada. Esta tarefa pode ser uma tarefa em si ou parte de uma tarefa maior. Nesta abordagem, não é possível saber a quem pertence a tarefa e se ela é parte de uma tarefa maior. Por exemplo, um programa de usuário em execução em um sistema multiprogramado suportando a preempção é composto de várias pequenas tarefas, cada uma realizada entre duas interrupções do processador. Em outras palavras, parte desta tarefa é executada pelo processador, até que ocorra uma interrupção avisando que o tempo para aquela microtarefa se esgotou. O escalonador (outra tarefa) executa então e decide qual microtarefa deve ser executada em seguida. Perde-se, assim, a noção de unidade que o modelo de processo apresenta. Naquele modelo, existe um processo escalonador, um processo para cada tarefa que envolve um programa em execução. Na abordagem baseada em interrupções, tudo ocorre em função das interrupções: perde-se a noção de um todo que o processo representa. Running Blocked Ready Figura 2. Diagrama de transição de estados de um processo [TAN92]. Algoritmos de Escalonamento. Na literatura, existem vários algoritmos de escalonamento de processos. O mais simples adota uma política justa: o primeiro processo na fila de processos prontos

6 executa. Esta política respeita a ordem da fila e considera que processos não são preemptados (interrompidos). Apesar de simples, não é comum. As políticas mais implementadas são baseadas em fatias de tempo (também chamada de quanta - plural de quantum de tempo) e em prioridades ou, mais comumente, uma mistura dos dois. Um processador executa um processo durante uma fatia de tempo. Ao término desta fatia, o processo é desescalonado e passa para o final da fila de processos prontos para executar. Um processo naturalmente pode não usar toda a fatia disponível: ele pode-se bloquear por algum motivo antes que a fatia termine. Esta estratégia baseada em fatias é conhecida como round-robin. Em um esquema de prioridades, o próximo processo a ser executado após um desescalonamento deve ter prioridade maior, sendo, eventualmente, um processo não preemptável (interrompível). Implementação de Processos. A fim de implementar o modelo de processos, o sistema operacional mantém uma tabela chamada de tabela de processos, com uma entrada por processo. As principais informações contidas nesta tabela são (tomando Unix como exemplo): informações relativas à gerência de processos valor dos registradores contador de programa (PC - program counter) que contém o endereço da próxima instrução a ser executada palavra de status do programa endereço da pilha do programa estado do processo (executando, pronto para executar, bloqueado) momento em que o processo iniciou tempo utilizado de processador tempo de processador utilizado pelos processos filhos (processos gerados pelo processo corrente) endereços para fila de mensagens bits de sinais pendentes identificador do processo (PID - Process ID) informações relativas à gerência de memória endereço do segmento de texto

7 7 endereço de segmento de dados inicializados endereço de segmento de dados não inicializados status de saída status de sinalização identificador do processo (PID - Process ID) identificador do processo pai identificador do grupo do processo identificador real e efetivo do usuário identificador real e efetivo do grupo informações relativas à gerência de arquivos máscara de acesso aos arquivos diretório raiz diretório corrente descritores de arquivos identificador efetivo do usuário identificador efetivo do grupo do usuário parâmetros de chamadas ao sistema Cada processo tem uma entrada na tabela de processos contendo todas ou parte das informações acima. Em geral, esta tabela fica residente em memória principal, cache ou mesmo em registradores especiais do processador, dependendo de características arquiteturais do computador. Quando um processo é desescalonado pelo escalonador ( perde a vez ), todas as informações pertinentes a este processo devem ser salvas na tabela de processos. O sistema operacional deve carregar, a partir da tabela de processos, o estado do próximo processo a carregar. A tabela de processos mantém informações sobre os processos. Mas o que é o processo propriamente dito? Ora, um processo é um programa em execução que consome principalmente dois recursos: processador e memória. Instruções e dados devem residir em cache, memória principal e mesmo em memória secundária (disco magnético, normalmente) quando o sistema dispõem de memória virtual. O espaço de memória ocupado por um processo é chamado de área de trabalho (workspace) e contém basicamente (usando novamente o modelo Unix de processo):

8 1. um segmento de texto: contém as instruções a serem executadas em linguagem de máquina; 2. um segmento de dados: contém os dados do programa. É composto de duas partes, um segmento de dados inicializados (em geral, constantes) e um segmento de dados não inicializados, cujo espaço não é alocado quando o processo inicia. Por esta razão, o segmento de dados não inicializados possui tamanho variável (pode ocorrer alocação dinâmica de memória); 3. um segmento de pilha (stack): contém variáveis do ambiente de execução, o string contendo a linha de comando e endereços de retorno de procedimentos. A Figura 3 apresenta o espaço de endereçamento de um processo Unix em execução. BSS corresponde à área de dados não inicializados de um processo Unix. Pilha BSS Dados Código Figura 3. Espaço de endereçamento de um processo típico em Unix [TAN92]. Em um sistema multiprogramado, diferentes processos se alternam na utilização do processador. O processador que executa um programa contém em seus registradores dados daquele programa,

9 9 eventualmente dados de controle (parte de tabelas), o contador corrente do programa e o espaço de trabalho (completo ou parcial) na memória. A tabela de processos está também na memória. Quando a fatia de tempo correspondente àquele processo termina (em um escalonamento baseado em fatias de tempo) ou quando uma operação causadora de bloqueio é executada, o processo deve ser desescalonado. Isto implica em salvar o contexto deste processo, ou seja, salvar em memória todas as variáveis de estado daquele processo. Em geral, isto implica em salvar conteúdo de registradores e tabelas. Não necessariamente o espaço de trabalho daquele processo sai da memória. Aliás ele deve ficar, visto que, em caso de desescalonamento por término da fatia de tempo, o processo voltará a executar em breve. Se o processo é bloqueado por alguma outra razão diferente do término da fatia de tempo, o processo é colocado em estado de bloqueado, aguardando algum evento a fim de que ele se desbloqueie (por exemplo, fim de uma operação de entrada e saída). Este salvamento de contexto possui tempos na ordem do milissegundo (se o salvamento for em disco) ou da ordem do microssegundo (se o salvamento for em RAM) e, se não for devidamente eficiente, pode comprometer o desempenho do sistema como um todo. Suponha agora que tal sistema multiprogramado seja utilizado para programação concorrente e pseudo-paralela. Pseudo-paralela pois, inicialmente, é considerado que se dispõem de um único processador. Com um processador, não se pode ter paralelismo real. Em um sistema monoprocessado, multiprogramado, vários processos devem cooperar a fim de resolver um único problema. Normalmente, um sistema multiprogramado suporta diferentes tarefas de diferentes usuários executando de maneira concorrente. Assim, temos uma edição de textos de um usuário X, em concorrência com uma compilação de um usuário Y, em concorrência com um shell (interpretador de comandos) de um usuário Z, e assim por diante. Nada impede de termos vários processos resolvendo um único problema de um único usuário. Isto não parece tão distante assim do quotidiano. Um ambiente de janelas normalmente funciona desta maneira. Cada janela tem um processo associado em execução. Existe um processo pai, normalmente o shell de origem, que, a pedido do usuário, lança diferentes processos correspondentes a diferentes janelas. Tudo isto gerenciado por um programa de controle de janelas. A comunicação, em geral, ocorre dos diferentes processos filhos para o processo pai, com fins de notificação de eventos. O gerenciador de janelas deve-se manter informado de tudo o que ocorre na tela.

10 A mesma abordagem poderia ser utilizada para resolver um problema menos visual e mais científico, por exemplo, uma multiplicação de matrizes ou uma simulação numérica. O objetivo é explorar o máximo de concorrência possível para ir mais rápido. Um processo que se bloqueia por entrada/saída pode ceder o processador para outro processo irmão que o está ajudando a resolver o mesmo problema. Em sistemas multiprogramados tradicionais, como Unix, apesar da cooperação, estes processos, para o sistema operacional, não são diferentes dos outros processos em execução dos outros usuários. Suponha que dois processos A e B cooperem para resolver um dado problema arbitrário X. Se A é desescalonado, nada é garantido se o próximo processo a ser executado é B. Pode ser, pode não ser, depende do número de processos em execução e, principalmente, da política de escalonamento adotada pelo sistema operacional. Eventualmente, uma prioridade mais alta pode ser concedida a A e a B, a fim de que eles, em concorrência com o sistema operacional, sempre executem, antes de qualquer outro processo de outro usuário. Mas, isto envolve um acordo externo ao sistema (o super usuário pode modificar a prioridade de processos: um usuário comum consegue abaixar a prioridade de seu processo, jamais subi-la). Assim, além de contar com um chaveamento de contexto nada diferente em relação ao chaveamento de contexto de outros processos, estes processos não compartilham o processador em conjunto. Outro aspecto a ser considerado é a separação das áreas de trabalho entre os diferentes processos, sejam eles cooperantes ou não (independentes). Um processo não tem acesso à área de trabalho de outro processo. Se um processo A precisa de dados de outro processo B, o processo B pode, por exemplo, escrever o dado em um arquivo e, em seguida, o processo A ler o arquivo com o dado. Outra possibilidade é o processo A enviar uma mensagem para B solicitando o dado e aguardar o processo B enviar para A uma outra mensagem com o dado solicitado. Estas são as duas maneiras básicas para dois processos comunicarem (a última depende de um suporte do sistema operacional para troca de mensagens). Qualquer outra maneira corresponde a uma variação dos métodos acima. A área compartilhada para comunicação pode ser um registrador, memória principal ou disco (no caso de arquivos). Em ambientes monoprocessados, a troca de mensagem entre processos também será feita através de uma memória compartilhada que conterá a mensagem a ser transmitida. Porém, se os processos residem em dois processadores distintos, interconectados por uma rede, então a mensagem trafegará pelo meio de interconexão (e.g., um barramento), constituindo uma mensagem, propriamente dita, enviada de uma máquina a outra. Quando dois processos se comunicam através de uma área comum, o acesso a esta área deve ser controlada de modo a permitir o acesso único por

11 11 um processo. A posição de uma memória pode ficar inconsistente (e a instrução associada), se dois ou mais processos tentarem atualizar esta posição de memória concorrentemente. Situações como esta podem levar às chamadas situações de corrida. Um exemplo é apresentado na Figura 4. Para contornar este problema de compartilhamento, diferentes mecanismos podem ser implementados, tanto em hardware quanto em software, através de primitivas de baixo nível ou primitivas mais abstratas. A literatura é extensa [SIL94][TAN92]: instruções do tipo TSL (Test and Set Lock), primitivas sleep e wakeup, semáforos, contadores de eventos, primitivas lock (tranca), monitores e mesmo mensagens (uma comunicação através de mensagens estabelece, por si, uma ordem de acesso ao dado: primeiro o dado é enviado e posteriormente recebido, jamais o contrário). Em algum momento, estas primitivas garantem uma atomicidade de execuções de primitivas de sincronização entre processos. Processo 1 Processo 2 counter :=2; counter := 0; counter := counter+1; counter := counter-1; Se a operação counter := counter+1; é decomposta em: registrador1 := counter; registrador1 := registrador1+1; counter := registrador1; e a operação counter := counter-1; é decomposta em: registrador2 := counter; registrador2 : = registrador2-1; counter := registrador; o processo pode ser desescalonado entre qualquer uma das sub-instruções acima, levando a possíveis diferentes valores de counter após a execução concorrente do processo 1 e do processo2. Figura 4. Um exemplo de situação de corrida. O esquema de processos fechados, comunicando-se através de memória compartilhada ou através de mensagens, é adequado? Algumas vantagens e desvantagens podem ser levantadas:

12 Vantagens: o espaço de trabalho de cada processo é devidamente protegido pelo sistema operacional que não permite que outros processos (sejam cooperantes ou não) obtenham acesso a espaços de trabalho de outros processos; um processo que participa em um grupo de processos cooperantes pode, por algum motivo, morrer sem afetar fisicamente os outros processos. Os processos cooperantes podem ficar todos bloqueados caso um ou mais deles morram. Mas se a aplicação for tolerante a falhas, dentro do próprio programa, existem mecanismos que prevêem este fenômeno. Os outros processos se adaptam em função da ausência do elemento falho. Desvantagens: suponha dois processos A e B cooperando para a realização de uma tarefa. Se o processo A, em execução, se bloqueia por algum motivo, logo no início da fatia de tempo a ele alocada, o outro processo B, que também auxilia a resolver o mesmo problema de A, provavelmente não será escalonado para preencher o resto da fatia não utilizado por A. Como não é possível prever com antecedência qual será o próximo conjunto de instruções a ser executada por um processo, nada se pode afirmar sobre quando um processo perderá o processador. Se se dá 10 unidades de tempo para um processo se executar e ele só executa uma unidade de tempo destes 10, por que não dar as 9 unidades de tempo restantes para outro processo cooperante associado? se fosse possível ordenar diferentes processos envolvidos na mesma computação de maneira consecutiva, o problema acima estaria resolvido. Porém, o tempo de chaveamento de contexto poderia ainda ser considerado alto. A pergunta que resta é: não seria possível reduzir o tempo de chaveamento de contexto destes processos, sabendo que estes processos cooperam? Será que, pelo fato deles cooperarem, alguma simplificação na implementação destes processos não poderia ser idealizada? uma forma de comunicação entre processos passa por um arquivo. Mesmo quando isto não é explícito (por exemplo, usando o pipe do Unix), o sistema de arquivos é acionado. Um acesso a arquivo é, em geral, muito mais lento do que um acesso puro à memória.

13 13 Em face destas vantagens e desvantagens, duas soluções poderiam ser adotadas: 1. reduzir o tempo de chaveamento de contexto e implementar mecanismos mais eficientes para comunicação entre processos 2. permitir que um processo lance outros processos com áreas de acesso comuns para comunicação e que estes processos filhos compartilhem em grupo a mesma fatia de tempo alocada ao processo pai É importante observar que a criação de processos é uma tarefa realizada com muita frequência. O problema é que os processos não compartilham nada entre si, quando muito, o segmento de texto (código), que é, por natureza, não modificável na maior parte dos casos. Existem esforços em direção à primeira solução: manter a proteção existente entre processos e realizar um chaveamento de contexto eficiente. O hardware pode auxiliar nesta operação. Resta resolver o problema do compartilhamento da fatia de tempo entre processos correlatos. Isto pode ser imposto automaticamente pelo sistema operacional, modificando a estratégia de escalonamento do sistema operacional e criando um campo na tabela de processos que indica se o processo participa de um grupo de processos cooperantes. Com tantas modificações, um novo tipo de processo pode ser idealizado: o processo leve, também conhecido como thread. É o que será visto em seguida. 2. Processos Leves ( Threads ) Segundo Feitelson e Rudolph [FR90], um sistema paralelo deve suportar dois tipos de modelos de processos. Os processos, ditos pesados, são aqueles mencionados na seção anterior. Eles permitem um projeto estruturado e modular de grandes sistemas, criando contextos distintos para cálculos independentes, separados e protegidos uns dos outros. Isto naturalmente é válido para usuários independentes. Threads permitem um paralelismo de granularidade mais fina; muitas threads podem existir dentro de um contexto de um processo, cooperando entre si a fim de realizar um dado cálculo e compartilhando o espaço de endereçamento, arquivos abertos, etc. [FR90]. Por granularidade mais fina, subentende-se que a unidade de cálculo realizada de maneira concorrente é menor do que a unidade de cálculo associada a um processo. Por exemplo, a granularidade de um processo é de

14 programa. A granularidade de uma thread pode ser de um procedimento dentro de um programa: isto é, procedimentos podem ser executados concorrentemente. A Figura 5 apresenta graficamente a diferença entre estas duas abstrações. Thread Contador de Programa Processos Pesados Figura 5. Processos e threads [TAN92]. É importante observar que um processo pesado visto anteriormente é composto de apenas uma thread (vide Figura 5). Por exemplo, um processo que corresponde à execução de um programa compilado em C, possui uma thread de controle que começa no main(), passa por todas as instruções do programa, inclusive instruções embutidas em procedimentos, e termina no último fecha-chaves do programa (fechando o bloco iniciado pelo main). Threads podem ser conhecidas também como processos leves. Em ambientes multiprocessados, diferentes threads podem ser executadas realmente em paralelo em diferentes processadores. Threads têm-se tornado populares porque possuem algumas características de processos pesados, mas podem ser executadas mais eficientemente [SIL94]. Histórico. A noção de uma thread, como um fluxo sequencial de controle, data de 1965, pelo menos, com o Berkeley Timesharing System. Naquela época, eram chamados de processos e não de threads. Processos interagiam através de variáveis compartilhadas, semáforos e mecanismos análogos. Max Smith desenvolveu um protótipo de implementação de threads sobre o sistema operacional Multics em Ele utilizou múltiplas pilhas em um processo pesado para suportar compilações em background. Talvez o ancestral mais importante das threads é a primtiva suportada pela linguagem PL/I, de cerca de A linguagem como definida pela IBM proporcionava uma chamada do tipo:

15 15 CALL XXX (A, B) TASK; que criava uma thread para XXX. Não está claro se os compiladores da IBM implementaram esta possibilidade, mas foi examinada em detalhes quando do desenvolvimento de Multics. Foi decidido que a chamada TASK como definido não mapeava em processos, desde que não havia proteção entre threads de controle. Assim, Multics tomou uma direção diferente, e a chamada TASK foi removida de PL/I pela IBM. Em seguida, surgiu Unix no início dos anos 70. A noção Unix de um processo transformou-se em uma thread única de controle sequencial mais um espaço de endereçamento virtual (incidentalmente, a noção Unix de processo derivou diretamente dos processos no projeto do Multics). Assim, processos em Unix são máquinas assaz pesadas, desde que eles não podem compartilhar memória entre si (cada processo tem o seu espaço de endereçamento, podendo comunicar-se através de pipes ou de mensagens). Após um certo tempo, usuários de Unix começaram a sentir falta dos velhos processos que compartilham memória. Isto levou às threads como as conhecemos hoje. O termo leves (lightweight) surgiu em finais da década de 70 ou início da década de 80, junto com os primeiros microkernels (Thot, Amoeba, Chorus, Mach). Como observação, é colocado que threads têm sido utilizadas em aplicações de telecomunicações por um longo tempo [NWS96]. O FAQ (Frequently Asked Questions - questões frequentemente colocadas: documento de um newsgroup Internet com as dúvidas mais comuns dos leitores daquele newsgroup) não comenta sobre a linguagem Algol (pelo menos da sua implementação nas máquinas de pilha da Burroughs) na qual threads concorrentes eram disparadas dentro de aplicações, sejam como co-rotinas (veja abaixo), sejam como threads assíncronas. Implementação de threads. Cada processo leve deve ter seu próprio contador de programa e sua própria pilha. Podem conter também uma área de dados privados. Threads podem criar outras threads e, como processos pesados, podem bloquear-se na espera de um evento. Threads compartilham o processador, da mesma maneira que processos pesados. Porém, diferentemente de processos pesados, uma thread bloqueada pode ceder o processador a outra thread do mesmo processo. Embora tenham seu próprio PC, sua pilha e dados privados, as threads se executam sobre um mesmo espaço de endereçamento, compartilhando variáveis globais se for o caso. Segundo Tanenbaum, não há proteção alguma entre threads, pois (1) é impossível (visto que todas elas atuam dentro do espaço de um único processo), e (2) em geral, não é necessário, pois estes processos leves

16 estão exatamente cooperando para resolver um problema comum e pertencem a um mesmo usuário. Threads possuem estados também, naturalmente: em execução, prontas para executar, bloqueadas e terminadas. Dentro deste modelo, é necessário caracterizar um processo leve como terminado, visto que outras threads podem estar em execução e o espaço de trabalho deixado pela thread que terminou ainda não tenha sido recolhido pela thread pai. Uma tabela de threads deve então ser mantida também. Os itens por thread são normalmente: o contador de programa; o endereço da pilha; o conjunto de registradores associados; endereços das threads filhas; estado. Resta para o processo, como um todo, informações do tipo endereço da área de trabalho, variáveis globais, apontadores para informações de arquivos abertos, endereços de processo filhos, informações sobre timers, sinais, semáforos e de contabilização. Threads podem ser síncronas ou assíncronas. Quando elas são síncronas, elas executam até que elas mesmas decidam não continuar a execução (ou termine a fatia de tempo para aquele processo que, ao voltar a executar, continuará executando a mesma thread interrompida). Isto facilita o mecanismo de compartilhamento de dados, pois jamais uma thread será interrompida, se ela não o quiser explicitamente. Threads assíncronas, por outro lado, podem executar umas com as outras, por exemplo, subdividindo a fatia de um processo equitativamente entre as threads ativas (não bloqueadas). Modelos de utilização de threads. O padrão de comportamento das threads dentro de um processo pode ser o mais variado possível. Por exemplo, Tanenbaum apresenta três organizações diferentes: a mestre/escravo, um modelo baseado em time ou equipe e um modelo baseado em pipeline. Na primeira configuração, existe uma thread mestre que recebe tarefas a serem realizadas e que as despacha para outras threads que efetivamente realizarão as tarefas (uma por thread, por exemplo). Um servidor de arquivos pode ser estruturado desta maneira. Existe uma thread que recebe pedidos

17 17 de abertura de arquivos. Para cada arquivo, o mestre designa uma thread escrava que se encarregará de gerenciar um arquivo cuja abertura foi solicitada. É aquela thread escrava que lerá ou escreverá no arquivo a qual ela é responsável. No modelo de time, é possível imaginar threads com habilidades diferentes: por exemplo, uma somente lê arquivos, outra somente realiza cálculos com números inteiros, outra acolá somente realiza operações sobre números com ponto flutuante. Da mesma maneira que uma equipe de operários pode levantar uma casa, as diferentes threads podem resolver um dado problema. O modelo em pipeline (ou em duto) é análogo a uma linha de montagem, onde diferentes threads, também especializadas, realizam diferentes operações sobre dados que são passados de thread em thread, como um carro sendo montado em uma linha de produção. Pacotes de threads. As primitivas de manipulação de threads são em geral disponíveis através de bibliotecas ou de pacotes (thread packages). Um primeiro problema a ser abordado é se threads são criadas estatica ou dinamicamente. No caso estático, o número de threads é definido em tempo de redação ou de compilação do programa. A pilha alocada para cada thread é de tamanho fixo. No caso dinâmico, que é o mais habitual, threads são criadas sob demanda pelo programa. Quase sempre, o nome da primitiva de criação de threads envolve o termo fork, também bastante utilizado para criação de processos pesados. Entre diversos parâmetros, os mais importantes são o nome do procedimento que está sendo associada a thread, parâmetros para o procedimento, tamanho da pilha e até mesmo uma prioridade de escalonamento, prioridade está válida somente dentro do contexto do processo com a thread pai. É possível criar um esquema de prioridades entre threads de um mesmo processo. O processo, por sua vez, possui uma prioridade externa usada pelo escalonador do sistema operacional. A prioridade do processo, como vimos, em geral não é modificada pelo usuário. Assim como processos, threads podem terminar normalmente com a execução do fim do procedimento, ou podem ser mortas por outras threads. Threads podem comunicar-se através das variáveis globais do processo que as criou. A utilização destas variáveis pode ser controlada através de primitivas de sincronização (monitores, semáforos, ou construções similares). Primitivas existem para bloqueio do processo que tenta obter acesso a uma área da memória que está correntemente sendo utilizada por outro processo. Primitivas de sinalização de fim de utilização de recurso compartilhado também existem. Estas primitivas podem acordar um ou mais processos que estavam bloqueados. É importante observar que variáveis globais, embora úteis em alguns contextos, devem ser evitadas em outros. Valores de status de

18 operações de entrada/saída são em geral armazenadas em variáveis globais. O exemplo de [TAN92] é a variável errno que é global a todas as threads. Se uma thread realiza uma abertura de arquivo para leitura e algum problema ocorre (e.g., o arquivo não existe), a variável errno conterá um código de operação inválida. Porém, antes de testá-la para tomar alguma providência, a thread é desescalonada e outra thread passa a ser executada pelo processador. Esta mesma thread realiza outra operação de entrada e saída com sucesso e a mesma variável errno conterá o valor de um código válido de status. Quando a outra thread voltar a executar ela enxergará um valor errôneo da variável status. Implementação de pacotes de threads. [TAN92] apresenta duas maneiras possíveis de implementar threads: uma no espaço do usuário e outra no espaço do sistema operacional. Na primeira opção, o kernel do sistema operacional não tem conhecimento da existência das threads. Para o kernel, existem processos pesados que são executados intercaladamente. A vantagem é que pacotes deste tipo podem ser utilizados em sistemas operacionais que não suportam threads (por exemplo, Unix padrão como SunOS). O escalonamento das diferentes threads é gerenciado por uma camada de software abaixo das threads e acima do kernel. Chamadas de sistema não são realizadas: toda a gerência da execução das threads é feita pelo run time system (veja Figura 6). Outras vantagens são a flexibilidade do escalonamento (o usuário pode até mesmo programar o seu próprio algoritmo) e a extensibilidade ou escalabilidade (scalability): se as threads fossem todas gerenciadas pelo kernel, este se tornaria um gargalo e o desempenho cairia com o aumento do número de threads. Em pacotes de threads gerenciados pelo sistema operacional, não há necessidade de uma camada adicional de software. Para cada processo ativado, existe uma tabela de threads com informações sobre o seu estado. Esta tabela também existe no caso de pacotes a nível de usuário, mas a mesma agora se encontra em um espaço de trabalho do sistema operacional. Qualquer operação relativa a uma thread é implementada com uma chamada de sistema, o que envolve um overhead maior. Quando uma thread se bloqueia, o sistema pode executar outra thread do mesmo processo ou uma thread de outro processo.

19 19 Threads Threads User Space Run time system Kernel User-level threads package Kernel Space Kernel Kernel-level threads package Figura 6. Pacotes de threads a nível de usuário e a nível de sistema [TAN92]. Comparando as duas abordagens, observa-se que threads a nível de usuário jamais podem bloquear. Se uma delas bloqueiam, todas as outras ficam bloqueadas e o processo como um todo é desescalonado. Uma solução seria dispor de chamadas de sistemas não bloqueantes, mas isto envolveria mudanças no sistema operacional subjacente. Pode-se descobrir antes de executar uma instrução se ela vai bloquear ou não (algo como um comando do tipo probe - ou sonda). Se uma instrução vai bloquear, o pacote pode então decidir executar outra thread. Este comando de sonda implica em modificações na biblioteca de chamadas de sistema. Jacket é o nome dado ao código associado em torno de uma chamada de sistema a fim de fazer esta verificação. Escalonamento round-robin não é possível entre threads executando dentro de um quantum de tempo do processador, pois interrupções de relógio não ocorrem neste intervalo (a não ser que seja explicitamente solicitada tal interrupção). Isto quer dizer que se uma thread começa a executar, ela o fará até terminar a fatia de tempo alocada para o processo como um todo ou a thread explicitamente se bloquear ou passar para o estado ready. Threads são necessárias em aplicações onde uma concorrência pode ser explicitada e ocorra muitos bloqueios (por exemplo, uma aplicação I/O- Bound, que realiza muita entrada/saída e pouco cálculo). Outros problemas podem ocorrer para ambos os casos: problema de código de biblioteca compartilhado e dados globais por processo. Reentrância. O desenvolvimento de aplicações com múltiplas threads requer um ambiente com suporte a compartilhamento de código (ou reentrância) entre threads. Solaris, por exemplo, proporciona versões reentrantes para a maioria das bibliotecas comumente utilizadas. Correntemente, Solaris não proporciona versões seguras a threads das bibliotecas Motif e

20 OpenLook, que são raramente utilizadas por múltiplas threads em um programa. Windows NT também proporciona versões reentrantes para a maioria de suas bibliotecas de uso comum. Depuração. A depuração de aplicações multithreaded é um grande desafio e pode ser frustrante sem o suporte de um depurador ciente de threads. Solaris suporta um depurador multithreaded como parte de seu ambiente SPARCworks/iMPact, enquanto o depurador NT multithreaded faz parte de Visual C++. Além de mostrar as threads por processo, ambos os depuradores suspendem e resumem threads e inspecionam variáveis por thread. Co-rotinas. Threads que não são preemptiveis e podem somente ser um único fluxo ativo de controle dentro de um processo (não importando o número de processadores disponíveis) são referidas como co-rotinas. Programação com co-rotinas requer uma abordagem bem diferente da programação baseada em threads. Isto porque os problemas de sincronização e de compartilhamento de recursos que ocorrem em ambientes com threads não perturbam o programador de co-rotinas. Threads e Sistemas Distribuídos e Concorrentes. As threads são de interesse particular em sistemas distribuídos e concorrentes. Como vimos, módulos em sistemas concorrentes são, em geral, mais complexos do que módulos em sistemas sequenciais. Por exemplo, um procedimento pode estar associada a uma ou mais threads concorrentes que interagem através de uma memória comum ou através de passagem de mensagens. Assim, uma relação simples de entrada e saída (característica de procedimentos de programas sequenciais) não é adequada para descrever o comportamento de um procedimento, desde que os seus estados intermediários internos podem estar visíveis aos clientes através de outras interações. Interfaces em procedimentos concorrentes incluem não somente pontos de entrada e de retorno, mas também pontos intermediários que podem interagir com outras threads. Módulos em sistemas concorrentes podem também ser ativos: eles podem ter threads internas em background, cujo efeito em algum lugar deve ser descrito em uma especificação [WEI93]. Futuro. Outros sistemas operacionais são multithreaded: NextStep, OS/2, AIX (e outros Unix), e Windows95. Versões futuras do sistema operacional de Macintosh serão também multithreaded. 3. Exemplos