THREAD 6.1 Introducgao Até 0 final da década de 1970, sistemas operacionais, como Tops-10 (DEC), MVS (IBM) e Unix (Bell Labs), suportavam apenas processos com um inico thread (mo- nothread), ou seja, um processo com apenas um jinico programa fazendo parte do seu contexto. Em 1979, durante o desenvolvimento do sistema operacional Toth, foi introduzido 0 conceito de processos lightweight (peso leve), onde o espago de recamento de um processo era compartilhado pu: varios programas. Apesar do con- ceito revolucionario, a idéia nao foi utilizada comercialmente, e somente em meados de 1980, com o desenvolvimento do sistema operacional Mach na Universidade de Carnegie Mellon, ficou clara a separagdo entre o conceito de progesso ¢ thread ende- A partir do coneeito de miitiplos threads (multithread) & possivel projetar e implementar aplicagdes concorrentes de forma eficiente. pois um processo pode ter partes diferentes da seu cédigo sendo executadas em paralelo, com um menor overhead do que utilizando miil- tiplos proc de enderegamento, a comuinicago entre threads ndo envolve mecanismos lentos de interco- municago entre processos, aumentando. conseqiientemente, o desempenho da aplicagao. 108. Como 0s threads de um mesmo processo compartilham © mesmo espago O desenvolvimento de programas que exploram os beneficios da programagio mul tithread nao é simples. A presenga do paralelismo introduz um novo conjunto de pro- _,blemas como a comunicagdo ¢ sincronizagao de threads. Existem diferentes modelos para a implementagao de threads em um sistema operacional, onde desempenho, fle- xibilidade 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 utilizagao comer- cial de sistemas operacionais multithread & crescente em fungao do aumento de po- pularidade dos sistemas com miltiplos processadores, do modelo cliente- dos sistemas distribuidos, ervidor & 6.2 Ambiente Monothread Um programa ¢ uma seqiiéncia de instrugdes, composta por desvios, repeti chamadas a procedimentos e furgdes. Em um ambiente monothread, um processo84 | Arquitetura de Sistemas Operacionais suporta apenas um programa no seu espaco de enderegamento. Neste ambiente, apli- cagdes concorrentes so implementadas apenas com 0 uso de multiplos processos in- dependentes ou subprocessos, A.utilizagdo de processos independentes e subprocessos permite dividir uma aplica~ do em partes que podem trabathar de forma concorrente. Um exemplo do uso de canicorréneia pode ser encontrado nas aplicagdes com interface grafica, como em um software de gerenciamento de e-mails. Neste ambiente, um usuario pode estar lendo suas mensagens antigas, ao mesmo tempo que pode estar enviando e-mails e rece- bendo novas mensagens. Com o uso de méiliptos provessos, cada funcionalidade do software impticaria a criagiio de um novo processo pata atendé-la, aumentando 0 de- sempenho da aplicagdo (Fig. 6.1). © problema neste tipo de implementagio € que o uso de processos no desenvolvi- mento de aplicagdes concorrentes demanda consumo de diversos recursos do siste- ma. 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, 0 sistema dispensa tempo para desalocar recursos previamente alocados, Outre problema a ser considerado é quanto ao compartilhamento do espago de ende- regamento, Como cada processo possui seu proprio espago de enderegamento, a co- municagdo entre processos toma-se dificil ¢ lenta, pois utiliza mecanismos como pipes, sinais, semaforos, meméria compartilhada ou troca de mensagem, Além disto. © compartilhamenta de recursos comuns aos processos concorrentes, como meméria € arquivos abertos, ndo é simples. Na Fig. 6.2 existe trés processos monothreads, Processos Independentes Fig. 6.1 Concorréncia com subprocessos € processos independentes.Thread / 88 Fig. 6.2 Ambiente monothread cada um com seu proprio contexto de hardware, contexto de software ¢ espaco de en- deregamento So exemplos de sistemas monothread 0 Microsoft MS-DOS e as primeiras versdes do MS-Window’s. Mesmo em ambientes multiprogramaveis e multiusuatio, encon- tramos exemplos de implementagdes monethread, como nas versdes mais antigas dos sistemas VAX VMS e Unix. 6.3 Ambiente Multithread Em um ambiente multithread. ov seja, com miltiplos threads, nao existe a idéia de programas associados a processos. mas, sim, a threads, O processo, neste ambiente, tem pelo menos um thread de execugao, mas pode compartilhar 0 seu espago de en- derecamento com inumeros outros threads. Na Fig. 6.3 existe apenas um proceso com trés threads de execugao compartilhando 0 mesmo espago de enderegamento Contexto se hardware Contexto de hardware Contexto de Software Thread 1 Theeod2 Thread 3 fenderesamento Fig. 6.3 Ambiente multihread.86 / Arquitetura de Sistemas Operacionais De forma simplificada, um thread pode ser definido como uma sub-rotina de um programa que pode ser executada de forma assincrona, ou seja, executada paralela- mente ao programa chamador, O programador deve especificar os threads, asso. 40-08 is sub-rotinas assineronas, Desta forma, um ambiente multithread possibilita a execugdo concorrente de sub-rotinas dentro de um mesmo processo. nm Na Fig. 6.4 existe um programa principal que realiza a chamada de duas sub-rotinas assineronas (Sub_] e Sub_2). Inicialmente. 0 processo é criado apenas com o Thread_I para a execugdo do programa principal. Quando o programa principal cha- ma as sub-rotinas Sub_I ¢ Sub_2, sio criados os Thread_2 e Thread_3. respectiva- mente, e executados independentemente do programa principal. Neste processo, os trés threads sio executados concorrentemente Espaco de ‘enderesamento Thread_} ve Programe Pipe! Call Sub_T Contexto de Hardware Call Sub_2 Contexto de Hardware Thread_3 Contexto de Hardware Fig, 6.4 Aplicagao Mulithread (2).Thread / 87 No ambiente multithread, cada proceso pode responder a varias solicitagdes concor- rentemente ou mesmo simultaneamente. caso haja mais de um processador. A grande vantagem no uso de threads é a possibilidade de minimizar a alocagao de recursos do sistema, além de diminuir 0 overhead na criagdo, troca ¢ eliminagao de processos. Threads compartilham o processador da mesma maneira que processos e passam pe- las mesmas mudangas de estado (execugdo, espera € pronto). Por exemplo, enquan- to um thread espera por uma operagao de E/S, outro thread pode ser executado, Para permitir a troca de contexto entre os diversos threads, cada thread possui seu proprio contexto de hardware, com o contetido dos registradores gerais, PC e SP. Quando um thread esta sendo executado, seu contexto de hardware est armazenado nos regis- tradores do processador. No momento em que o thread perde a utilizagao da UCP, as informagdes so atualizadas no seu contexto de hardware. Dentro de um mesmo processo. threads compartilham 0 mesmo contexto de softwa- re € espago de enderegamento com os demais threads, porém cada thread possui seu contexto de hardware individual, Threads so implementados intemamente através de uma estrutura de dados denominada bloco de controle do thread (Thread Control Block ~ TCB), © TCB armazena. além do contexto de hardware, mais algumas in- formagdes relacionadas exclusivamente ao thread, como prioridade, estado de exe- cugio e bits de estado. Em ambientes monothread, o processo ¢ ao mesmo tempo a unidade de alocagao de recursos ¢ a unidade de escalonamento. A independéncia entre os coneeitos de pro- cesso ¢ thread permite separar a unidade de alocagao de recursos da unidade de es- calonamento, que em ambientes monothread estdo fortemente relacionadas. Em um ambiente multithread. a unidade de alocagdo de recursos € 0 processo, onde todos os seus threads compartilham o espago de enderegamento, descritores de arquivos e dis- positives de E/S, Por outro lado. cada thread representa uma unidade de escalona- mento independente. Neste caso. 0 sistema no seleciona um processo para a execugiio, mas sim um de seus threads. A grande diferenga entre aplicagdes monothread e multithread estd no uso do espa- go de enderecamento. Processos independentes e subprocessos possuem espagos de enderegamento individuais e protegidos, enquanto threads compartilham © espago dentro de um mesmo proceso. Esta caracteristica permite que 0 compartilhamento de dados entre threads de um mesmo processo seja mais simples e ripido, se com- parado a ambientes monothread Como threads de um mesmo processo compartilham © mesmo espago de endereca- mento, nao existe qualquer protego no acesso 4 mem ‘ria, permitindo que um thread possa alterar facilmente dados de outros. Para que threads trabalhem de forma coo- perativa, ¢ fundamental que a aplicagao implemente mecanismos de comunicagio e sineronizagao entre threads, a fim de garantir o acesso seguro aos dados comparti- thados na memoria. © uso de multithreads proporciona uma série de beneficios. Programas concorrentes com miiltiplos threads sio mais répidos do que programas concorrentes implemen- tados com miiltiplos processos, pois operagdes de criagao, troca de contexto e elimi- nagio dos threads geram menor overhead (Tabela 6.1). Como os threads dentro de um processo divide o mesmo espago de enderecamento, a comunicagao entre eles88 / Arquitetura de Sistemas Operacionals Tabela 6.1 Laténcia de processos e threads (Vahalia, 1996) Implementagae ‘Tempo de Criacio (us) ‘Tempo de Sincronizagio (1s) Provesso 700 200 Processo Lightweight [ 35) 0 | Thread 2 66 pode ser rzalizada de forma rapida e eficiente. Além disso, threads em um mesmo processo podem compartilhar facilmente outros recursos, como descritores de arqui- vos, temporizadores, sinais, atributos de seguranga ete, A.utilizagdo do processador, dos discos e de outros periféricos pode ser feita de for- ma concorrente peios diversos threads, significando melhor utilizag3o dos recursos computacionais disponiveis. Em algumas aplicagdes. a utilizagao de threads pode melhorar o desempenho da aplicagdo apenas executando tarefas em background en- quanto operagdes E/S esto sendo processadas (Fig. 6.5). Aplicagdes como editores Fig, 6.5 Aplicagao multithread (b)Thread» 89 de texto, planilhas, aplicativos grificos e processadores de imagens sio especial- mente beneficiados quando desenvolvidos com base em threads. Em ambientes cliente-servidor, threads sio essenciais para solicitagdes de servigos remotos. Em um ambiente monothread. se uma aplicagao solicita um servigo remo- to, ela pode ficar esperando indefinidamente, enquanto aguarda pelo resultado. Em um ambiente multithread, um thread pode solicitar 0 servigo remoto, enquanto a aplicagao pode continuar realizando outras atividades. Ja para o processo que aten- de a solicitagdo, miltiplos threads permitem que diversos pedidos sejam atendidos simultaneamente (Fig. 6.6). Processo servidor Solicitacoes -\@ rts Processe cliente Proceszo cliente -—~Processo cliente Fig. 6.6 Aplicagao multthread (c) Nao apenas aplicagdes tradicionais podem fazer uso dos beneficios do multithrea- ding. O micleo do sistema operacional também pode ser implementado com o uso desta técnica de forma vantajosa, como na arquitetura microkernel, apresentada no capitulo Estrutura do Sistema Operacional. 6.4 Arquitetura e Implementagao © conjunto de rotinas disponiveis para que uma aplicagio utilize as facilidades dos threads ¢ chamado de pacote de threads. Existem diferentes abordagens na imple- mentagdo deste pacote em um sistema operacional, o que influenciara no desempe- nho, na concorréncia e na modularidade das aplicagdes multithread.90 / Arquitetura de Sistemas Operacionais Threads podem ser oferecidos por uma biblioteca de rotinas fora do nucleo do siste- ma operacional (modo usuario), pelo proprio nucleo do sistema (modo kemel), por uma combinagao de ambos (modo hibrido) ou por um modelo conhecido como sche- duler activations. A Tabela 6.2 resume as diversas arquiteturas para diferent bientes operacionais. am- Tabela 6.2 Arquitetura de threads para diversos ambientes operacionais Ambientes Arquitetura Distributed Computing Environment (DCE Modo usuirio Compaq OpenVMS versio 6 1 Modo usuirio Microsoft Windows 2000 ~_Modokemel ‘Compaq Univ Modo kernel Compaq OpenVMS versio 7 ‘Modo kernel Sun Solaris vers Moda hibride University of Washingion FasrThreads Scheduler activations Uma das grandes dificuldades para a utilizagao de threads foi a auséncia de um pa- dro, Em 1995, 0 padrdo POSIX P1003.1¢ foi aprovado e posteriormente atualizado cido como Pthreads. \gdes comerciais multithreading tornaram-se mais simples e de facil implemen- io. O padriio Pthreads ¢ largamente utilizado em ambientes Unix. como o Sun Solaris Pthread e o DECthreads para Digital OSF/1 para a versio POSIX 1003.4a. Com este padrao, também conh apli 6.4.1 THREADS EM Mobo UsuArio Threads em modo usuério (TMU) sio implementados pela aplicagio ¢ nio pelo sis- tema operacional. Para isso, deve existir uma biblioteca de rotinas que possibilite 4 aplicagdo realizar tarefas como criagdo/eliminacdo de threads, troca de mensagens entre threads e uma politica de escalonamento. Neste modo, o sistema operacional nio sabe da existéncia de miltiplos threads. sendo responsabilidade exclusiva da aplicagdo gerenciar e sincronizar os diversos threads existentes. A vantagem deste modelo é a possibilidade de implementar aplicagdes multithreads mesmo em sistemas operacionais que ndo suportam threads. Utilizando a biblioteca, miltiplos threads podem ser criados. compartilhando o mesmo espago de enderega- mento do processo, além de outros recursos (Fig. 6.7). TMU sao ripidos ¢ eficientes por dispensarem acessos ao kernel do sistema operacional, evitando assim a mudan- ga de modo de acesso (usuario-kemel-usuario). TMU possuem uma grande limitagio, pois o sistema operacional gerencia cada pro- cesso como se existisse apenas um Unico thread. No momento em que um thread chama uma rotina do sistema que 0 coloca em estado de espera (rotina bloqueante), todo 0 processo & colocado no estado de espera, mesmo havendo outros thread: prontos para execugdo. Para contornar esta limitagao, a biblioteca tem que possuir rotinas que substituam as rotinas blogueantes por outras que nao possam causar 0Modo vusuério Modo keornel Fig. 6.7 Threads em modo usuario bloqueio de um thread (rotinas ndo-bloqueantes), Todo este controle é transparente para 0 usuario e para o sistema operacional. Talvez um dos maiores problemas na implementagaio de TMU seja o tratamento in- dividual de sinais. Como o sistema reconhece apenas processos endo threads, os si- nais enviados para um processo devem ser reconhecidos e encaminhados a cada thread para tratamento, No caso do recebimento de interrupgdes de clock, fundamen- tal para a implementagao do tempo compartilhado, esta limitagdo é critica, Neste ca- 50, 05 sinais de temporizagio devem ser interceptados, para que se possa interromper © thread em execugao e realizar a troca de contexto. Em relagdo ao escalonamento em ambientes com miiltiplos processadores, ndo & possivel que multiplos threads de um processo possam ser executados em diferentes UCPs simultaneameme, pois o sistema seleciona apenas processos para execuco € no threads. Esta restrigdo limita drasticamente o grau de paralelismo da aplis {jd que os threads de um mesmo processo podem ser executados em somente um pro- cessador de.cada vez. 6.4.2 THREADS EM Mopo KERNEL Threads em modo kernel (TMK) sao implementados diretamente pelo niicleo do siste- ‘ma operacional, através de chamadas a rotinas do sistema que oferecem todas as fun- gdes de gerenciamento e sincronizagdo (Fig. 6.8). O sistema operacional sabe da existéncia de cada thread e pode escaloné-los individualmente. No caso de miltiplos processadores, 0s threads de um mesmo processo podem ser executados simultanea- mente © grande problema para pacotes em modo kemel ¢ 0 seu baixo desempenho, Enquanto nos pacotes em modo usuario todo tratamento é feito sem a ajuda do tema operacional. ow seja, sem a mudanga do modo de acesso (usudrio-kernel-usud- rio). pacotes em modo kernel utilizam chamadas a rotinas do sistema e. conseqiientemente, varias mudangas no modo de acesso, A Tabela 6.3 compara 0 de- sempenho de duas operacdes distintas envolvendo a criagdo, escalonamento, execu- cdo e eliminagao de um processo thread.92 | Arquitetura de Sistemas Operacionais Modo. Fig. 6.8 Threads em modo kernel Tabela 6.3 Comparacdo entre tempos de laténcia (Anderson et al., 1992) 2s) Subprocessos 17,300 7x0 Threads em Modo Kernel O48 1 Threads em Modo Usui uu Implementagio Operagio 1 (us) ‘Opera 6.4.3 THREADS EM Mono Hisripo A arquitetura de threads em modo hibrido combina as vantagens de threads imple- mentados em modo usuario (TMU) e threads em modo kernel (TMK). Um processo pode ter virios TMK e, por sua vez, um TMK pode ter varios TMU. O niicleo do sis- tema reconhece 0s TMK e pode escaloné-los individualmente. Um TMU pode ser executado em um TMK, em um determinado momento, e no instante seguinte set executado em outro O programador desenvolve a aplicagdo em termos de TMU e especifica quantos TMK estio associados ao proceso, Os TMU siio mapeados em TMK enquanto o processo esta sendo executado, O programador pode utilizar apenas TMK, TMU ou uma combinagao de ambos (Fig. 6.9), O modo hibrido, apesar da maior flexibilidade, apresenta problemas herdados de am- bas as implementagdes. Por exemplo, quando um TMK sealiza uma chamada blo- queante, todos os TMU sio colocados no estado de espera, TMU que desejam utilizar varios processadores devem utilizar diferentes TMK, 0 que influenciara no desempenho. 6.4.4 SCHEDULER ACTIVATIONS Os problemas apresentados no pacote de threads em modo hibrido existem devido & falta de comunicagio entre os threads em modo usuario ¢ em modo kernel. O mode- lo ideal deveria utilizar as facilidades do pacote em modo kernel com o desempenho ¢ flexibilidade do modo usuario,Thread 93 Modo usvério Biblioteca" rwco | soicr [race | soa Modo Poem Fig. 6.9 Threads em modo hibrido Introduzido no inicio da década de 1990 na Universidade de Washington, este paco- te combina o melhor das duas arquiteturas, mas em vez de dividir os threads em mo- do usuario entre os de modo kernel, 0 nucleo do sistema troca informagdes com a biblioteca de threads utilizando uma estrutura de dados chamada scheduler activa- tions (Fig. 6.10) A maneira de aleangar um melhor desempenho ¢ evitar as mudangas de modos de acesso desnecessirias (uswirio-kernel-usuirio). Caso um thread utilize uma chama- da ao sistema que o coloque no estado de espera, nio € necessario que 0 kernel seja ativado, bastando que a prépria biblioteca em modo usuario escalone outro thread. Isto & possivel porque a biblioteca em modo usuario ¢ o kernel se comunicam e tra balham de forma cooperativa. Cada camada implementa seu escalonamento de for- ma independente, porém trocando informagdes quando necessirio. at vet Fig, 6.10 Scheduler activations.94 / Arquitetura de Sistemas Operacionais 6.5 Modelos de Programacao desenvolvimento de aplicagdes multithread nie é simples, pois exige que a comu- nicagdo e o compartilhamento de recursos entre os diversos threads seja feito de for- ma sineronizada para evitar problemas de inconsisténcias ¢ deadlock. Além das dificuldades naturais no desenvolvimento de aplicagdes concorrentes. © procedimen- to de depuragao é bastante complexo. Lm fator importante em aplicagdes multithread é 0 nimero total de threads e a for- ma come sao criados e eliminados. Se uma aplicagao cria um numero excessivo de threads, poder ocorrer um ovethead no sistema, ocasionando uma queda de desem- penho. Dependendo da implementaciio. a definigio do niimero de threads pode ser dinami- ca ou estitica. Quando a criagdo/eliminagdo é dinamica, os threads sao criados/eli- minados conforme a demanda da aplicagao, oferecendo grande flexibilidade. Ja em ambientes estaticos, o niimero de threads ¢ definido na criagdio do processo onde a aplicago sera executada. Para obter os beneficios do uso de threads, uma aplicagao deve permitir que partes diferentes do seu codigo sejam executadas em paralelo de forma independente. Se um aplicativo realiza varias operagdes de E/S e trata eventos assineronos, a progra- macao muitithread aumenta seu desempenho até mesmo em ambientes com um tni- co processador, Sistemas gerenciadores de banco de dados (SGBDs), servidores de arquivos ou impressio sio exemplos onde 0 uso de miltiplos threads proporciona grandes vantagens e beneficios. 6.6 Exercicios 1. Como uma aph thread? Quais os problemas de aplicagdes concorrentes desenvolvidas em ambientes mo- nothread? O que é um ambiente multithread e quais as vantagens de sua utilizagio? 4. Explique a diferenca entre unidade de alocagao de recursos ¢ unidade de escalo- namento. 5. Quais as vantagens e desvantagens do compartilhamento do espaco de endere- samento entre threads de um mesmo proceso? 6, Compare os pacotes de threads em modo usuario e modo kernel Qual a vantagem do scheduler activations comparado ao pacote hibride? 8. Dé exemplos do uso de threads no desenvolvimento de aplicativos como edito- res de textos e planilhas eletrénicas 9. Como o uso de threads pode melhorar o desempenho de aplicagdes paralelas em ambientes com miiltiplos processadore: 10. Quais os beneficios do uso de threads em ambientes cliente-servidor? 11. Como 0 uso de threads pode ser itil em arquiteturas microkernel? 9 pode implementar concosténcia em um ambiente mono-SINCRONIZAGAO E COMUNICAGAO ENTRE PROCESSOS 7.1 Introdugaéo Na década de 1960, com o surgimento dos sistemas multiprogramaveis, passou a ser possivel estruturar aplicagdes de maneira que partes diferentes do cédigo do programa pudessem executar concorrentemente, Este tipo de aplicagio, denominado aplicaciio concorrente, tem como base a execugio cooperativa de multiplos processos ou threads, que trabalham em uma mesma tarefa na busca de um resultado comum. Em um sistema multiprogramavel com nico processador, os processos altemam sua execuigdo segundo critérios de escalonamento estabelecidos pelo sistema operacional Mesmo nao havendo neste tipo de sistema um paralelismo na execugao de instrugdes, uma aplicagdo concorrente pode obter methoras no seu desempenho, Em sistemas com miiltiplos processadores, a possibilidade do paralelismo na execugao de instrugdes somente estende as vantagens que a programagdo concorrente proporciona, E natural que processos de uma aplicagaio concorrente compartilhem recursos do sis- tema, como arquivos, registros, dispositivos de E/S e areas de meméria. O comparti- Ihamento de recursos entre processos pode ocasionar situagdes indesejaveis, capazes até de comprometer a execugio das aplicagdes. Para evitar esse tipo de problema, os processos concorrentes devem ter suas execugdes sincronizadas, a partit de mecanis- mos oferecidos pelo sistema operacional, com o objeti-o de garantir 0 processamento correto dos programas, Este capitulo apresenta como a concorréncia de processos pode ser implementada, os pro- blemas do compartilhamento de recursos, solugdes e mecanismos do sistema operacional para sineronizar processos como semiforos e monitores. No final do capitulo ¢ também apresentado o problema do deadlock. suas conseqiiéncias e andlise de solugdes. 7.2 Aplicagdes Concorrentes Muitas vezes, em uma aplicagdo concorrente, ¢ nec quem-se entre si, Esta comunicagao pode ser implementada através de diversos meca- sdrio que processos comuni-96 | Arquitetura de Sistemas Operacionais nismos, como varidveis compartilhadas na meméria principal ou trocas de mensagens. Nesta situagdo, é necessario que os processos concorrentes tenham sua execugao s cronizada através de mecanismos do sistema operacional A Fig, 7.1 apresenta um exemplo onde dois processos concorrentes compartitham um buffer para trocar informagdes através de operacdes de gravagao ¢ leitura. Neste exem- plo, um processo sé poder gravar dados no buffer caso este nao esteja cheio. Da mesma forma, um proceso s6 poder ler dados armazenados do buffer caso exista algum dado para ser lido. Em ambas as situagdes, os processos deverao aguardar até que 0 butter esteja pronto para as operagdes, seja de gravacio, seja de leitura. Sineronizagao Oo Processo s Processo gravador Ye leitor dado Buffer Fig. 7.1 Sincronizagao e comunicag30 entre processos Os mecanismos que garantem a comunicagdo entre processos concorrentes ¢ 0 acesso a recursos compartilhados sio chamados mecanismos de sincronizagdo. No projeto de sistemas operacionais multiprogramaveis, € fundamental a implementagdo destes mecanismos para garantir a integridade ¢ a confiabilidade na execucio de aplicagée: concorrentes. Apesar de o termo processo ser utilizado na exemplificagdo de aplicagdes concor- rentes, os termos subprocesso e thread tém o mesmo significado nesta abordagem. 7.3 Especificagao de Concorréncia em Programas Existem varias notagdes utilizadas para especificar a concorréncia em programas, ou seja, as partes de um programa que devem ser executadas concorrentemente. As técni- cas mais recentes tentam expressar a concorréncia no cédigo dos programas de uma forma mais clara e estruturada, A primeira notago para a especificagdo da concorréncia em um programa foram os comandos FORK e JOIN, introduzidos por Conway (1963) e Dennis ¢ Van Horn (1966). © exemplo a seguir apresenta a implementagao da concorréncia em um pro- grama com uma sintaxe simplificada:Sincronizagdo e Comunicagao entre Processos / 97 PROGRAM Az PROGRAM By OIN B; END. END. O programa A comeca a ser executado e, a0 encontrar 0 comando FORK, faz.com que seja criado um outro proceso para a execugo do programa B, concorrentemente a0 programa A. O comando JOIN permite que 0 programa A sincronize-se com B, ou seja, quando o programa A encontrar o comando JOIN, s6 continuara a ser processado apos o término da execugio do programa B. Os comandos FORK e JOIN sao bastante pode- rosos e praticos, sendo tilizados de forma semelhante no sistema operacional Unix. Uma das implementagdes mais claras e simples de expressar concorréncia em um pro- grama € a utilizagdo dos comandes PARBEGIN e PAREND (Dijkstra, 1965a), que, posteriormente, foram chamados de COBEGIN e COEND. No decorrer deste capitu- lo, 0s comandos PARBEGIN e PAREND sero utilizados nos algoritmos apresentados. O comando PARBEGIN especifica que a seqiiéncia de comandos seja executada con- correntemente em uma ordem imprevisivel, através da criagio de um proceso (Processo_1, Processo_2, Processo_n) para cada comando (Comando_l, Comando_2, Comando_n). © comando PAREND define um ponto de sincronizacao, onde o processamento sé continuaré quando todos os processos ou threads criados ja tiverem terminado suas execugdes. Os comandos delimitados pelos comandos PAR- BEGIN e PAREND podem ser comandos simples, como atribuigdes ou chamadas a procedimentos (Fig. 7.2). Para exemplificar 0 funcionamento dos comandos PARBEGIN e PAREND em uma aplicagio concorrente, o programa Expressao realiza 0 calculo do valor da expressio aritmética descrita a seguir: X i= SORT 024) + (35.4 * 0.23) - (302 / 7) Os comandos de atribuigdo situados entre PARBEGIN ¢ PAREND sao executados concorrentemente. 0 caleulo final de X s6 pode ser realizado quando todas as varia- veis dentro da estrutura tiverem sido calculadas.98 | Arquitetura de Sistemas Operacionais Processo prineipel a Processo | Processo n Processo principal Fig. 7.2 Concorréncia em programas. 7.4 Problemas de Compartilhamento de Recursos Para a compreensio de como a sincronizagao entre processos concorrentes & funda- mental para a confiabilidade dos sistemas multiprogramaveis, so apresentados alguns problemas de compartilhamento de recursos. A primeira situagao envolve o comparti- thamento de um arquivo em disco: a segunda apresenta uma variével na meméria prin- cipal sendo compantihada por dois processos. primeito problema é analisado a partir do programa Conta_Corrente, que atualiza 0 saldo bancério de um cliente apés um langamento de débito ou crédito no arquivo de contas-correntes Arq_Contas. Neste arquivo so armazenados os saldos de todos osSincronizagao e Comunicagao entre Processos / 99 cortentistas do banco. O programa Ié 0 registro do cliente no arquivo (Reg_Cliente), 18 © valor a ser depositado ou retirado (Valor_Dep_Ret) e, em seguida, atualiza o saldo no arquivo de contas. PROGRAM Conta_Corrente; READ (Arq_Contas, Reg Cliente); READLN (Valor_Dep Ret); Reg_Cliente.Saldo WRITE (Arq_Contas, Reg Cliente); END. Reg_Cliente.Saldo + Valor_Dep_Rets Considerando processos concorrentes pertencentes a dois funciondrios do banco que atualizam 0 saldo de um mesmo cliente simultaneamente, a situagao de com- partilhamento do recurso pode ser analisada. O processo do primeiro funcionario (Caixa 1) 1é 0 registro do cliente ¢ soma ao campo Saldo o valor do langamento de débito. Antes de gravar 0 novo saldo no arquivo, 0 processo do segundo fun- cionario (Caixa 2) lé 0 registro do mesmo cliente, que esté sendo atualizado, para realizar outro langamento, desta vez de crédito. Independentemente de qual dos processos atualize primeiro 0 saldo no arquivo, o dado gravado estar inconsis- tente. Caixa _Comando _ Saldo arquivo Valor dep/ret_— Saldo membria 1 READ 1.000 * 1.000 1 READLN 1.000 200 1.000 1 = 1.090 -200 800 2 BEAD 000 * 1.000 2 READIN 1.000 +300 1.000 2 co 1.000 +300 1.300 1 RITE 800 200 800 2 RITE 1.300 +300 1.300 Um outro exemplo, ainda mais simples, onde o problema da concorréncia pode levar a resultados inesperados, & a situagdo onde dois processos (A e B) executam um coman- do de atribuigdo. O Processo A soma 1 a varidvel X ¢ 0 Proceso B diminui | da mesma variavel que esté sendo compartilhada. Inicialmente, a variével X possui o valor 2. Processo A Processo B100 / Arquitetura de Sistemas Operacionais Seria razodvel pensar que o resultado final da variivel X, aps a execugiio dos Processos A e B, continuasse 2, porém isto nem sempre sera verdade. Os comandos de atribuigdo, em uma linguagem de alto nivel, podem ser decompostos em comandos mais elementares, como visto a seguir Processo B LOAD x, Rp SUB 1,85 STORE Rp, x Considere que o Proceso A carregue © valor de X no registrador Ra, some 1 e, no ‘momento em que vai armazenar o valor em X, seja interrompido. Nesse instante, 0 Processo B inicia sua execugdo, carrega o valor de X em Rp e subtrai 1. Dessa vez, 0 Processo B é interrompido ¢ 0 Processo A volta a ser processado, atribuindo o valor 3 a varivel X concluindo sua execugdo. Finalmente, o Processo B retorna a execugao, atribui o valor 1 a X, ¢ sobrepae o valor anteriormente gravado pelo Proceso A. O valor final da viriavel X ¢ inconsistente em fungdo da forma concorrente com que os dois processos executaram. Processo Comand: x Ra Rb LOAD X,Ra ADD 1,Fa LOAD X/Rp SUB 1,Rp STORE Ra, X STORE Rp, X . 1 vrooe Analisando os dois exemplos apresentados, é possivel concluir que em qualquer situa- ¢a0, onde dois ou mais processos compartilham um mesmo recurso, devem existir mecanismos de controle para evitar esses tipos de problemas, conhecidos como race conditions (condigdes de corrida).. 7.5 Excluséo Mutua A solugdo mais simples para evitar os problemas de compartilhamento apresentados no item anterior & impedir que dois ou mais processos acessem um mesmo recurso simul- taneamente, Para isso, enquanto um processo estiver acessando determinado recurso, todos os demais processos que queiram acessi-lo deverdo esperar pelo término da uti- lizago do recurso. Essa idéia de exclusividade de acesso é chamada exclusdo miitua (mutual exclusion) A exclusio miitua deve afetar apenas 0s processos concorrentes somente quando um deles estiver fazendo acesso ao recurso compartilhado. A parte do cédigo do programa onde ¢ feito © acesso a0 recurso compartilhado é denominada regido critica (critical region). Se for possivel evitar que dois processos entrem em suas regides criticas a0 mesmo tempo, ou seja, se for garantida a execugio mutuamente exclusiva das regides criticas, os problemas decorrentes do compartilhamento serio evitados.Sincronizagao ¢ Comunicagao entre Processos / 101 Os mecanismos que implementam a exclusdo mutua utilizam protocolos de acesso & regifo critica, Toda vez que um processo desejar executar instrugdes de sua regido critica, obrigatoriamente deverd executar antes um protocolo de entrada nessa regido. Da mesma forma, ao sair da regio critica um protocolo de saida deveri ser executado, Os protocolos de entrada ¢ saida garantem a exclusdo miltua da regido critica de um programa, c olo de Entra Protocolo de Saida *) Utilizando o programa Conta_Corrente apresentado no item anterior, a aplicagao dos protocolos para dois processos (A B) pode ser implementada no compartithamen- to do arquivo de contas-correntes. Sempre que o Processo A for atualizar o saldo de um cliente, antes de ler o registro 0 acesso exclusivo ao arquivo deve ser garantido através do protocolo de entrada da sua regio critica. O protocolo indica se jé existe ou nao algum proceso acessando 0 recurso. Caso 0 recurso esteja livre, o Processo A pode entrar em sua regifio critica para realizar a atualizagao, Durante este periodo, caso 0 Processo B tente acessar 0 arquivo, o protocolo de entrada faz com que esse processo permaneca aguardando até que 0 Processo A termine 0 acesso ao recurso. Quando 0 Processo A terminar a execugdo de sua regifo critica, deve sinalizar aos demais processos concorrentes que 0 acesso ao recurso foi concluido, Isso é realiza- do através do protocolo de saida, que informa aos outros processos que 0 recurso j4 esti livre e pode ser utilizado de maneira exclusiva por um outro processo. Como é possivel, entio, observar, para garantir a implementagao da exclusio mitua 0 processos envolvidos devem fazer acesso aos recursos de forma sincronizada. Diversas solugées foram desenvolvidas com esse propésito; porém, além da garan- tia da exclusio miitua, duas situagdes indesejadas também devem ser evitadas. A primeira situago indesejada & conhecida como starvation ou espera indefinida Starvation é a situagdo em que um proceso nunca consegue executar sua regido eri- tica e, conseqtientemente, acessar 0 recurso compartithado. No momento em que um recurso alocado ¢ liberado, o sistema operacional possuii um critério para selecionar, dentre os processos que aguardam pelo uso do recurso, qual sera o escolhido, Em fungo do critério de escolha, o problema do starvation pode ocorrer. Os critérios de escolha aleatéria ou com base em prioridades so exemplos de situagSes que podem gerar o problema, No primeiro caso, nao ¢ garantido que um processo em algum momento faré 0 uso do recurso, pois a selecao é randémica, No segundo caso, a baixa prioridade de um processo em relagao aos demais pode impedir o processo de acessar 0 recurso compartithado, Uma solugdo bastante simples para o problema & a criagdo de filas de pedidos de alocago para cada recurso, utilizando o esquema FIFO, Sempre que um processo solicita um recurso, o pedido ¢ colocado no final da fila associada ao recurso. Quando 0 recurso é liberado, o sistema seleciona o primei- ro processo da fila.102 / Arquitetura de Sistemas Operacionais Outra situagdo indesejada na implementaco da exclusio miitua é aquela em que um processo fora da sua regio critica impede que outros processos entrem nas suas pré- Drias regides criticas. No caso de esta situaeo ocorrer, um recurso estaria livre, porém alocado a um processo. Com isso, varios processos estariam send impedidos de util zat 0 recurso, reduzindo 0 grau de compartilhamento. Diversas solugdes foram propostas para garantir a exelusfio matua de processos con- correntes. A seguir, so apresentadas algumas solugdes de hardware e de software com discussdes sobre beneficios e problemas de cada proposta. 7.5.1 SoLu¢Ges DE HARDWARE A exclustio miitua pode ser implementada através de mecanismos de hardware. Neste item sdo apresentadas as solugSes de desebilitago de interrupgdes ¢ instrugGes test- and-set. * Desabilitacao de interrupcées A solugdo mais simples para 0 problema da exclusio miitua é fazer com que © pro- cesso desabilite todas as interrupgdes antes de entrar em sua regido critica, e as rea- bilite apés deixar a regio critica. Como a mudanga de contexto de processos s6 pode ser realizada através de interrupgdes, 0 processo que as desabilitou tera aces- so exclusivo garantido, BEGIN Desabilita_tnte Regiao_Critica; Habilita_ END. Esta solugio, apesar de simples, apresenta algumas limitagdes. Primeiramente, a multiprogramagao pode ficar seriamente comprometida, ja que a concorréncia entre processos tem como base o uso de interrupgdes. Um caso mais grave pode- ria ocorrer caso um proceso desabilitasse as interrupgGes e nao tomasse a habili- ti-las, Neste caso, o sistema, provavelmente, teria seu funcionamento seriamente comprometido. Em sistemas com miiltiplos processadores, essa solugio toma-se ineficiente devido ao tempo de propagacao quando um processador sinaliza aos demais que as inter- rupgdes devem ser habilitadas ou desabilitadas. Outra consideragiio é que o meca- nismo de clock do sistema é implementado através de interrupgdes, devendo esta solugdo ser utilizada com bastante critério. Apesar das limitagdes apresentadas, essa solugdo pode ser util quando se deseja que a execugdo de parte do miicleo do sistema operacional ocorra sem que haja interrupdo. Dessa forma, o sistema pode garantir que no ocorrerzo problemas de inconsisténcia em suas estruturas de dados durante a execugao de algumas rotinas.Sincronizagao e Comunicagao entre Processos / 103 * Instrucao test-and-set Muitos processadores possuem uma instrugdo de maquina especial que permite ler uma varidvel, armazenar seu conteddo em uma outra area ¢ atribuir um novo valor & ‘mesma varidvel. Essa instrugdo especial é chamada instrupdo test-and-set e tem como caracteristica ser executada sem interrupgdo, ou seja,trata-se de uma instrugio indivi- sivel. Dessa forma, é garantido que dois processos no manipulem uma variavel com- partilhada ao mesmo tempo, possibilitando a implementagao da exclusio miitua, A instrugdo test-and-set possui o formato a seguir, e quando executada o valor ligico da varidvel Y é copiado para X, sendo atribuido a variavel Y o valor légico verdadeiro. Test-and-Set (X,Y); Para coordenar o acesso concorrente a um recurso, a instrugdo test-and-set utiliza uma variavel ldgica global, que no programa Test_and_Set é denominada Bloqueio. Quando a variavel Bloqueio for falsa, qualquer proceso poder alterar seu valor para verdadeiro através da instrugdo test-and-set e, assim, acessar 0 recurso de forma exclusiva. Ao terminar © acesso, 0 processo deve simplesmente retornar 0 valor da varidvel para falso, liberando 0 acesso ao recurso. PROGRAM Test_and_Set; VAR Bloqueio : BOOLEAN; PROCEDURE Processo_Ay VAR Pode_A : BOOLEAN; BEGIN REPEAT Pode_A := Truer WHILE (Pode_A) DO Test_and Set (Pode A, Bloqueio); Regiao_Critica_A; Bloqueio := False; UNTIL False; END; PROCEDUI VAR Pode _B : BOOLEAN; BEGIN REPEAT Pode_B := True; WHILE (Pode_B) DO Test_and_Set (Pode 8, Bloqueio): Regiao Critica B; Bloqueio := False; L False; Processo_B; u END; BEGIN Bloqueio PARBEGIN Processo_Ai Processo_B; PAREND; Falser END.104 / Arquiteture de Sistemas Operacionais - Pode_A Bloqueio REPEAT * . False 2 REPEAT * : False a Pode A i= True Tee . False 2 Pode B i= True » True 8 WHILE . True B : False a True . a True . 3 . False A Teue * A True * 3 False 3 . False 8 REPER’ : False A WHILE * A Tect_and * : Pel > 0 uso de uma instrugdo especial de maquina oferece algumas vantagens, como a simplicidade de implementagao da exclusto muitua em miltiplas regides criticas ¢ o uso da solugdo em arquiteturas com mulltiplos processadores. A principal desvanta- gem é a possibilidade do starvation, pois @ selegdo do processo para acesso ao recur- so ¢ arbitriria, 7.5.2 SoLucdes DE SOFTWARE Diversos algoritmos foram propostos na tentativa de implementar a exclusiio miitua através de solugdes de software. As primeiras solugdes tratavam apenas da exclusdo miitua para dois processos e, inicialmente, apresentavam alguns problemas, A seguir é apresentado de forma evolutiva como foi o desenvolvimento de uma solugdo definit va para a exclustio mtitua entre N processos. * Primeiro algoritmo Este algoritmo apresenta uma solugdo para exclusio miitua entre dois processos, onde um mecanismo de controle alterna a execugao das regides criticas. Cada pro- cesso (A e B) é representado por um procedimento que possui um loop infinito, (REPEAT/UNTIL), onde € feito 0 acesso a um recurso por diversas vezes. A seqiiéncia de comandos, dentro do loop, ¢ formada por um protocolo de entrada, uma regio critica © um protocolo de sada. A regido critica é representada por uma rotina, onde o acesso ao recurso realmente acontece. Apds 0 acesso & regio critica, tanto 0 Processo A quanto o Processo B realizam processamentos individuais. © mecanismo utiliza uma varidvel de bloqueio, indicando qual processo pode ter acesso a regido critica, Inicialmente, a varidvel global Vez é igual a ‘A’, indicando que 0 Processo A pode executat sua regio critica. © Processo B, por sua vez, fica esperando enquanto Vez for igual a ‘A’. O Proceso B s6 executard sua regio eriti- ca quando 0 Processo A atribuir o valor ‘B’ a varivel de bloqueio Vez. Desta forma, estara garantida a exclustio mitua entre os dois processos.Sincronizagao e Comunicagao entre Processos / 105 WHILE (Vez = ‘B’) DO (* Nao Regiao Critica Ay Vez r= ‘BY; Processamento_A; UNTIL False: (vez = ‘A') DO (* faz nada *) Regiao Critica B; Vez i= ‘AY; Processamento False; Processo Ay Processo Este algoritmo, apesar de implementar a exclusio mitua, apresenta duas limitagdes, das quais a primeira surge do proprio mecanismo de controle utilizado, O acesso ao recurso compartilhado s6 pode ser realizado por dois processos e sempre de manei: ra alternada. Com isso, um processo que necessite utilizar 0 recurso mais vezes do que outro, permanecera grande parte do tempo bloqueado. No algoritmo apresenta- do, caso 0 Processo A pemanega muito tempo na rotina Processamento_A, é possi vel que o Proceso B queira executar sua regio critica e nao consiga, mesmo que 0 Processo A nao esteja utilizando o recurso. Como 0 Processo B pode executar seu loop mais rapidamente que o Processo A, a possibilidade de executar sua regio cri tica fica limitada pela velocidade de processamento do Processo A. Processo_A Processo_B vez WHILE (Vez = ‘BY) WHILE (Vez = ‘A") a Regiao_Critica A WHILE (Vez = ‘A’) a vez i= ‘Bt WHILE (Vez = ‘A") B Processamento_A Regiao Critica B 5 Processamento_A vez i= ‘AY A Processamento_A Processamento_8 A Processamento_A WHILE (Vez = “A") aA Outro problema existente nesta solugdo ¢ que, no caso da ocorréneia de algum pro- blema com um dos processos, de forma que a varivel de bloqueio ndo seja altera- da, 0 outro processo permanecera indefinidamente bloqueado, aguardando 0 acesso 0 recurso,106 / Arquitetura de Sistemas Operacionais * Segundo algoritmo problema principal do primeiro algoritmo & que ambos os processos trabalham com uma mesma varidvel global, cujo contetido indica qual processo tem o direito de entrar na regifio critica. Para evitar esta situagdo, 0 segundo algoritmo introduz uma varivel para cada processo (CA e CB) que indica se 0 processo esta ou nio em sua regio critica, Neste caso, toda vez que um processo desejar entrar em sua regio critica, a variavel do outro processo é testada para verificar se o recurso esta livre para uso. PROGRAM Algoritmo 2; VAR CA, CB : BOOLEAN; PROCEDURE Proceso, BEGIN REPEAT WHILE (CB) DO (* Nao faz nada CA i= true; Regiao_Critica_A; cA r= false; Processamento_A; UNTIL False IND: PROCEDURE Processo_B; BEGIN - REPEAT WHILE (CA) DO (* Nao faz nada *); CB i= true; Regiao Critica By cB := false Processamento_B; UNTIL False, END; BEGIN CA i= false; cB := false; PARBEGIN Processo_A; Processo_B; PAREND; END, Neste segundo algoritmo, o uso do recurso nao é realizado necessariamente altemna- do. Caso ocorra algum problema com um dos processo fora da regio critica, 0 outro processo nao ficara bloqueado, o que, porém, no resolve por completo o problema, Caso um processo tenha um problema dentro da sua regiio critica ou antes de alte- rar a variével, 0 outro processo permanecerd indefinidamente bloqueado. Mais grave que 0 problema do bloqueio é que esta solugdo, na pritica, é pior do que 0 primeiro algoritmo apresentado, pois nem sempre a exclusio miitua é garantida, O exemplo a seguir ilustra o problema, considerando que cada processo executa cada instrugao altemadamente. Processo_A Processo_B cA ca WHILE (cB) WHILE. (CA) false CA = true cB i= true true ocritica A Ragiao_Crit: trueSincronizagao e Comunicagao entre Processos | 107 * Terceiro algoritmo O tereeiro algoritmo tenta solucionar o problema apresentado no segundo, do a instrugio de atribuigdo das varidveis CA e CB antes do loop de teste. PROGRAM Algoritmo_3; WHILE (CB) DO (* Nao faz nada *); Regiao_Critica_A; ca := fale: ocessamento_Ay UNTIL False: END; PROCEDURE Processo_By BEGIN REPEAT cB i= trues WHILE (CA) DO (* Nao faz nada *); Regiao Critica B; CB i= false; Processamento_3; UNTIL False; END; Esta alteracio resulta na garantia da exclusdo mutua, porém introduz um novo pro- blema, que é a possibilidade de bloqueio indefinido de ambos os provessos, Caso os dois processos alterem as variiveis CA e CB antes da execugdo da instrugio WHILE, ambos os processos nao poderdo entrar em suas regides criticas, como se 0 recurso ja estivesse alocado, * Quarto algoritmo No tereeiro algoritmo, cada processo altera o estado da sua varidvel indicando que ir entrar na regiio critica sem conhecer 0 estado do outro processo, 0 que acaba resultando no problema apresentado. © quarto algoritmo apresenta uma implemen- taco onde o processo, da mesma forma, altera o estado da variavel antes de entrar na sua regiao critica, porém existe a possibilidade de esta alteragdo ser revertida108 / Arquitetura de Sistemas Operacion: PROGRAM Algoritmo_4; VAR CA,CB : BOOLEAN; PROCEDURE Processo_1 BEGIN REPEAT cA : WHILE (CB) DO BEGIN CA i= falser { pequeno intervalo de tempo aleatér cA := true END; Regia Critica A? cA := false; UNTIL False; ENO: PRO’ BEGIN REPEAT CB i= trues WHILE (CA) DO BEGIN CB im false { pequenc inervalo de tempo aleatér CB i= trues DURE Proceso 8: = false; PARBEGIN Processo_A; Processo_B; PAREND; END. Apesar de esta solugio gavantir a excluso miitua e néo gerar o bloqueio simultaneo dos processos, uma nova situagio indesejada pode ocorrer eventualmente. No caso de os tempos aleatirios s rem proximos ¢ a concorténcia gerar uma situagio onde 0s dois processos alterem as varidveis CA e CB para falso antes de término do loop, nenhum dos dois processos conseguir executar sua regido critica, Mesmo com esta situagdo nao sendo permanente, pode gerar alguns problemas. * Algoritmo de Dekker A primeira solugdo de software que garantiu a exclustio muitua entre dois processos, sem a incorréneia de outros problemas foi proposta pelo matematico holandés T. Dekker com base no primeiro e quarto algoritmos. O algoritmo de Dekker possui uma l6gica bastante complexa e pode ser encontrado em Ben-Ari (1990) e Stallings (1997), Posteriormente, G. L. Peterson propés outta solugao mais simples para 0 mesmo problema, conforme apresentado a seguir.Sincronizagao e Comunicagao entre Processos / 109 * Algoritmo de Peterson algoritmo proposto por G. L. Peterson apresenta uma solugdo para o problema da exclusio muitua entre dois processos que pode ser facilmente generalizada para 0 caso de N processos. Similar ao terceiro algoritmo, esta solugdo, além das variiveis de condigdo (CA e CB) que indicam o desejo de cada processo entrar em sua regio critica, introduz a variavel Ver pata resolver os conflitos gerados pela concorréncia. Antes de acessar a regio critica, o processo sinaliza esse desejo através da variavel de condigao, porém o proceso cede 0 uso do recurso ao outro processo, indicado pela variavel Vez. Em seguida, o proceso executa 0 comando WHILE como proto- colo de entrada da regio critica. Neste caso, além da garantia da exclusio mitua, 0 bloqueio indefinido de um dos processos no loop nunca ocorrerd, ja que a variavel ‘Vez sempre permitira a continuidade da execugdo de um dos processos. Algoritmo_Peterson; A,CB: BOOLEAN; LE (CB and Vez = ‘B') DO (* Nao faz nada *); Regiao_ Critica Ay c false; ssamento_A 1 False; “A WHILE (CA and Vez = ‘A’) DO (* Nao faz nada *); Regiao_Critica_| cB ser Processamento_B; False; false: PARBEGIN Processo_Ar Processo_B; PAREND; END.110 / Arquitetura de Sistemas Operacionais * Algoritmo para exclusdo miitua entre N processos algoritmo de Dekker ¢ a versio inicial do algoritmo de Peterson garantem a exclusdo miitua de dois processsos. Posteriormente, o algoritmo de Peterson foi generalizado para 0 caso de N processos Hofri (1990). O algoritmo do Padeiro (Bakery Algorithm), proposto por Lamport (1974), é uma solueio classica para o problema da exclusto miitua entre N processos e pode ser encontrado em Ben-Ari (1990) e Silberschatz, Galvin e Gagne (2001). Outros algoritmos que também foram apresentados para exclustio miitua de N processos podem ser consultados em Peterson (1983) e Lamport (1987). “Apesar de todas solugdes até entio apresentadas implementarem a exclusio mitua, todas possuiam uma deficiéncia conhecida como espera ocupada (busy wait). Na espera ocupada, toda vez que um processo ndo consegue entrar em sua regio criti- ca, por jé existir outro processo acessando 0 recurso, o processo permanece em loo- ping, testando uma condig&o, até que the seja permitido 0 acesso. Dessa forma, 0 processo em looping consome tempo do processador desnecessariamente, podendo ocasionar problemas ao desempenho do sistema. ‘A solugdo para 0 problema da espera ocupada foi a introdug&o de mecanismos de sincronizago que permitiram que um processo, quando nao pudesse entrar em sua regitio critica, fosse colocado no estado de espera. Esses mecanismos, conhecidos como semforos e monitores, so apresentados posteriormente. cronizacao Condicional Sincronizacdo condicional & uma situago onde 0 acesso ao recurso compartilhado exige a sincronizago de processos vinculada a uma condigéo de acesso. Um recurso pode nao se encontrar pronto para uso devido a uma condigao especifica. Nesse caso, © processo que deseja acessi-lo deveré permanecer bloqueado até que o recurso fique disponivel. Um exemplo clissico desse tipo de sincronizagdo ¢ a comunicagio entre dois proces- sos através de operagies de gravagao e leitura em um buffer, como foi visto na Fig. 7.1, onde processos geram informagies (processos produtores) utilizadas por outros processos (processos consumidores). Nessa comunicagao, enquanto um processo ‘grava dados em um buffer, o outro Ié os dados, concorrentemente. Os processos envol- vidos devem estar sincronizados a uma varidvel de codigo, de forma que um proces- so nio tente gravar dados em um buffer cheio ou realizar uma leitura em um buffer vazio. programa a seguir exemplifica o problema da sincronizagéo condicional, também conhecido como problema do produtor/consumidor ou do buffer limitado, O recurso compartilhado é um buffer, definido no algoritmo com o tamanho TamBuf e sendo con- trolado pela varidvel Cont. Sempre que a varivel Cont for igual a 0, significa que o buf- fer esti vazio e 0 processo Consumidor deve permanecer aguardando até que se grave um dado. Da mesma forma, quando a variével Cont for igual a TamBuf, significa que © buffer esté cheio e o processo Produtor deve aguardar a leitura de um novo dado, Nessa solugdo, a tarefa de colocar e retirar os dados do buffer é realizada, respectiva-Sincronizagao e Comunicacao entre Pracessos ( 111 mente, pelos procedimentos Grava_Buffer ¢ Le_Bufler, executados de forms mtaa- mente exclusiva. Nao esta sendo considerada, neste algoritmo, a implementago de cexclusio miitua na variével compartilhada Cont. PROGRAM Produtor_Consumidor 17 CONST TamBuf = (* Tamanho qualquer *); TYPE Tipo Dado = (* Tipo qualquer *); VAR Buffer : ARRAY [1..TamBuf] OF Tipo_Dado; Dado_1 : Tipo_Dados Dado_2 : Tipo Dado; Cont; 0, .TamButy PROCEDURE Produtor? BEGIN REPEAT Produz_Dado (Dado_1)+ WHILE (Cont = TamBuf) DO (* Nao faz nada * Grava_Buffer (Dado_i, Buffer); Cont t= Cont + 1; UNTIL False; END; PROCEDURE Consumidor; BEGIN REPEAT WAILE (Cont = 0) DO (* Nao faz nada ¥); Le Buffer (Dado_2, Buffer); Consome_Dado (Dado_2); Cont UNTIL False; END; cont — 1: BEGIN Cont PARBEGIN Produtor; Consumidor; PAREND; END. Apesar de o algoritmo apresentado resolver a questio da sincronizagdo condicional, o problema da espera ocupada também se faz presente, sendo somente solucionado pelos ‘mecanismos de sincronizago semiforos e monitores. 7.7. Semaforos conceito de seméforos foi proposto por E. W. Dijkstra em 1965, sendo apresentado como um mecanismo de sincronizacao que permitia implementar, de forma simples, a exclusio miitua e sincronizagdo condicional entre processos. De fato, o uso de semi- foros tornou-se um dos principais mecanismos utilizados em projetos de sistemas ope- racionais e em aplicagdes concorrentes. Atualmente, a maioria das linguagens de programagao disponibiliza rotinas para uso de seméforos. Um seméforo é uma varidvel inteira, ndo-negativa, que sé pode ser manipulada por duas instrugdes: DOWN e UB, também chamadas originalmente por Dijkstra instru-112 / Arquitetura de Sistemas Operacionais Ges P (proberen, teste em holandés) eV (verhogen, incremento em holandés). As ins- trugdes DOWN e UP sio indivisiveis, ou seja, a execugdo destas instrugdes nao pode ser interrompida. A instrugio UP incrementa uma unidade ao valor do seméforo, enquanto a DOWN decrementa a varivel. Como, por definigao, valores negativos nao podem ser atribuidos a um seméforo, a instrugdo DOWN executa em um semé- foro com valor 0, faz com que 0 processo entre no estado de espera, Em geral, essas instrugdes so implementadas no processador, que deve garantir todas essas condi- gies. Os semaforos podem ser classificados como bindrios ou contadores. Os semdforos bindrios, também chamados de mutexes (mutual exclusion semaphores), s6 podem assumir 0s valores 0 € 1, enquanto os seméforos contadores podem assumir qualquer valor inteiro positivo, além do 0. AA seguir, serd apresentado o uso de seméforos na implementaciio da exclusio miitua da sincronizagio condicional. Ao final deste item, alguns problemas clissicos de sin- cronizagao so também apresentados. 7.7.1 ExcLusko Mutua UTILIZANDO SEMAFOROS A exclustio mtitua pode ser implementada através de um semiforo binério associado ao recurso compartithado. A principal vantagem desta solugo em relago aos algorit- mos anteriormente apresentados é a nio ocorréncia da espera ocupada. As instrugdes DOWN e UP funcionam como protocolos de entrada e saida, respecti- vamente, para que um processo possa entrar e sair de sua regio critica. O semaforo fica associado a um recurso compartilhado, indicando quando o recurso esta sendo acessado por um dos processos concorrentes. O valor do seméforo igual a 1 indica que nenhum processo esté utilizando 0 recurso, enquanto 0 valor 0 indica que o recurso esta em uso. Sempre que deseja entrar na sua regio critica, um processo executa uma instrugo DOWN. Se o semiforo for igual a 1, este valor é decrementado, e 0 processo que soli- citou a operacdo pode executar as instrugdes da sua regido critica. De outra forma, se uma instrugdo DOWN é executada em um semaforo com valor igual a 0, 0 processo fica impedido do acesso, permanecendo em estado de espera e, conseqiientemente, nao gerando overhead no processador. O processo que esté acessando o recurso, ao sair de sua regido critica, executa uma ins- trugdo UP, incrementando 0 valor do semaforo e liberando 0 acesso ao recurso, Se um ‘ou mais processos estiverem esperando pelo uso do recurso (operagdes DOWN pen- dentes), 0 sistema selecionaré um processo na fila de espera associada ao recurso ¢ alterard o seu estado para pronto (Fig. 7.3).