Para que serve um sistema operacional?

medida que novos avanos foram sendo obtidos, procurando facilitar a leitura de dados e programas e a impresso de informaes, as linguagens de programao passaram a ter de lidar com essas novas interfaces. Os sistemas operacionais surgiram para organizar e facilitar a interao dos programas com tape drives, leitoras de carto e impressoras dentre outras coisas. Para isso, os sistemas operacionais servem como uma camada intermediaria entre os programas e a mquina, organizando a forma como os dados so lidos e as informaes impressas. O computador um equipamento elaborado principalmente a partir de um conjunto de processadores e circuitos eletrnicos preparados para execuo de tarefas lgicas baseadas em um conjunto de instrues fornecidas pelos usurios. Atualmente, essas instrues so fornecidas por programas especficos ou dispositivos adequados como teclado ou mouse. Nos primrdios da computao, conforme vimos, a entrada de dados era feita basicamente por meio de cartes perfurados. Pela definio anterior, bastaria o usurio ligar o computador e fornecer as instrues necessrias(disquete ou cartes) e o computador passaria a executar o que foi determinado. Por exemplo: 1)usurio deseja trabalhar com um editor de textos 2)Onde esta o editor de texto no disco? 3)Como carregar o editor de texto na memria, que est no disco? 4)Para gravar o texto digitado, onde est o espao vazio do disco? 5)o espao disponvel em disco suficiente? 6)Se for imprimir o texto, como enviar para impressora? 7)Como interpretar os comandos do mouse ou teclado? 8)A forma adotada por um programa para gravar os dados em disco, e aceito por outros programas? Se cada programa executado pelo usurio tivesse de cuidar dessas tarefas bsicas, sua complexidade cresceria tanto que seu desenvolvimento seria muito mais trabalhoso e demorado. O sistema operacional organiza o acesso bsico dos programas s funes bsicas do computador: -leitura e gravao em disco; -interpretar informaes enviadas pelo teclado e mouse; -transmisso de dados para uma impressora ou uma rede local; Dessa forma, o sistema operacional torna mais fcil tanto o desenvolvimento quanto a execuo dos programas.

THREAD 1.Introduo
At o final da dcada de 1970, sistemas operacionais, como Unix(Bell Labs), suportavam apenas processos com um nico thread(monothread), ou seja, um processo com apenas um nico programa fazendo parte do seu contexto. Em 1979, durante o desenvolvimento do sistema operacional Toth, foi introduzido o conceito de processos lightweight(peso leve), onde o espao de endereamento de um processo podia ser compartilhado por vrios programas. Somente em meados de 1980, com o desenvolvimento do sistema operacional Mach, ficou clara a separao entre o conceito de processo e thread. A partir do conceito de mltiplos threads(multhread) possvel projetar e implementar aplicaes concorrentes de forma eficiente, pois um processo pode ter partes diferentes do seu cdigo sendo executadas em paralelo. Como os threads de um mesmo processo compartilham o mesmo espao de endereamento, a comunicao entre threads no envolve mecanismos lentos de intercomunicao entre processos, no prejudicando o desempenho da aplicao. O desenvolvimento de programas que exploram os benefcios da programao multithread no simples, introduz um novo conjunto de problemas, como a comunicao e sincronizao de threads. Atualmente, o conceito de multithread pode ser encontrado em diversos sistemas operacionais, como o Microsoft Windows 2000 e no Sun Solaris.

2.Ambiente Monothread
Um programa uma seqncia de instrues, composta de desvios, repeties e chamadas a procedimentos e funes. Em um ambiente monothread, um processo suporta apenas um programa no seu espao de endereamento. Neste ambiente, aplicaes concorrentes so implementadas com uso de mltiplos processos independentes ou subprocessos

Um exemplo do uso de concorrncia pode ser encontrado nas aplicaes com interface grfica, como em um software de gerenciamento de e-mails, um usurio pode estar lendo email, enviando e-mail, e recebendo e-mail. O problema neste tipo de implementao que o uso de processos no desenvolvimento de aplicaes concorrentes demanda consumo de diversos recursos do sistema. Sempre que um novo processo criado, o sistema deve alocar recursos para cada processo, consumindo tempo de processador neste trabalho. Como cada processo possui seu prprio espao de endereamento, a comunicao entre processos torna-se difcil e lenta. Alem disto, o compartilhamento de recursos comuns aos processos concorrentes, como memria e arquivos aberto, no simples So exemplos de sistemas monothread: -MSDOS -primeiras verses WINDOWS -verses antigas do UNIX

3.Ambiente Multithread
Com mltiplos threads, no existe a idia de programas associados a processos, mas, sim, a threads. O processo, neste ambiente, tem pelo menos um thread de execuo, mas pode compartilhar o seu espao de endereamento com inmeros outros threads. Figura multithread De forma simplificada, um thread pode ser definido como uma sub-rotina de um programa que pode ser executada de forma assncrona, ou seja, executada paralelamente ao programa chamador. Existe um programa principal que realiza a chamada de duas sub-rotinas(sub1 e sub2). Inicialmente, o processo criado apenas com o thread_0 para execuo do programa principal. Quando o programa chama as sub-rotina sub1 e sub2, so criados os thread_1 e thread_2, respectivamente, e executados independentemente do programa principal. A grande vantagem no uso de threads a possibilidade de minimizar a alocao de recursos do sistema, alm de diminuir a alocao de recursos do sistema, e a criao, troca e eliminao de processos. Threads compartilham o processador da mesma maneira que processos e passam pelas mesmas mudanas de estado(execuo, espera e pronto). Por exemplo, enquanto um thread espera por uma operao de E/S, outro thread pode ser executado.

Para permitir a troca de contexto entre diversos threads, cada um possui seu prprio contexto de hardware, com contedo de registradores , PC e SP.Quando um thread esta sendo executado, seu contexto de hardware est armazenado nos registradores do processador. No momento que o thread perde a utilizao da CPU, as informaes so atualizadas no seu contexto de hardware. Dentro de um mesmo processo, threads compartilham o mesmo contexto de software e espao de endereamento com os demais threads, porm cada thread com seu contexto de hardware. Threads so implementados internamente atravs de uma estrutura de dados chamada TCBThread Control Block(bloco de controle do thread), que armazena, alm do contexto de hardware, mais algumas informaes relacionadas exclusivamente ao thread, como prioridade, estado de execuo, etc.. O uso de multithreads proporciona uma serie de benefcios. Programas com mltiplos threads so mais rpidos do que programas concorrentes implementados com mltiplos processos. Aplicaes como editores de texto, planilhas, processadores de imagens, so especialmente beneficiados quando desenvolvidos com base em threads.

4. Arquitetura e Implementao de threads

O conjunto de rotinas disponveis para que uma aplicao utilize as facilidades do threads e chamado de pacote de threads. Existem diferentes abordagens na implementao deste pacote em um sistema operacional. Threads podem ser oferecidos por uma biblioteca de rotinas, de 4 maneiras: - fora do ncleo do sistema operacional(modo usurio); - pelo prprio ncleo do sistema operacional(modo kernel); - por uma combinao de ambos(hbrido); - por um modelo conhecido como scheduler activations 4.1 Threads modo usurio (TMU) So implementados pela aplicao e no pelo sistema operacional. Para isso, deve existir uma biblioteca de rotinas que possibilite aplicao realizar tarefas como criao, eliminao, troca de mensagens entre threads e uma poltica de escalonamento. Neste modo, o sistema operacional no sabe da existncia de mltiplos threads, sendo responsabilidade exclusiva da aplicao gerenciar os threads existentes.

4.2 Threads modo Kernel(TMK) So implementados diretamente pelo ncleo do sistema operacional, atravs de chamadas a rotinas do sistema que oferecem todas as funes de gerenciamento e sincronizao. O SO sabe da existncia de cada thread e pode escalona-lo individualmente. No caso de mltiplos processadores, os threads de um mesmo processo podem ser executados simultaneamente. 4.3 Threads modo Hbrido Combina as vantagens do TMU e TMK. Um processo pode ter vrios TMK e, por sua vez, um TMK por ter vrios TMU. O ncleo do SO reconhece os TMK e pode escalona-los individualmente. Um TMU pode ser executado em um TMK, em um determinado momento,e um instante seguinte pode executar outro. 4.4.Scheduler Activations(agendamento) Os problemas apresentados no pacote de threads em modo hbrido existem devido falta de comunicao entre os threads em modo usurio e modo kernel. O modelo ideal deveria utilizar as facilidades do pacote em modo kernel com o desempenho e flexibilidade do modo usurio. Este pacote combina o melhor das duas arquiteturas, mas em vez de dividir os threads em modos usurio entre os de modo kernel, o ncleo troca informaes com a biblioteca de threads utilizando uma estrutura de dados chamada scheduler activations Caso um thread utilize uma chamada ao sistema que o coloque no estado de espera, no necessrio que o kernel seja ativado, bastando que a prpria biblioteca em modo usurio escalone outro thread. Cada camada implementa seu escalonamento de forma independente, porm trocando informaes quando necessrio.

Sincronizao e comunicao entre processos

1.Introduo Na dcada de 1960, com o surgimento dos sistemas multiprogramveis, passou a ser possvel estruturar aplicaes de maneira que partes diferentes do cdigo do programa pudessem executar concorrentemente. Este tipo de aplicao, denominado aplicao concorrente, tem como base a execuo cooperativa de mltiplos processos ou threads, que trabalham em uma mesma tarefa na busca de um resultado comum. Em um sistema multiprogramvel com nico processador, os processos alternam sua execuo segundo critrios de escalonamento estabelecidos pelo sistema operacional. natural que processos de uma aplicao concorrente compartilhem recursos do sistema, como arquivos, registros, dispositivos de E/S e reas de memria. O compartilhamento de recursos entre processos pode ocasionar situaes indesejveis, capazes at de comprometer a execuo das aplicaes. Para evitar esse tipo de problema, os processos concorrentes devem ter suas execues sincronizadas, a partir de mecanismos oferecidos pelo sistema operacional, com o objetivo de garantir o processamento correto do programas 2.Aplicaes concorrentes Em uma aplicao concorrente, necessrio que processos comuniquem-se entre si. Esta comunicao pode ser implementada atravs de diversos mecanismos, como variveis compartilhadas na memria principal. Temos um exemplo, onde dois processos concorrentes compartilham um buffer para trocar informaes atravs de operao de gravao e leitura: Um processo s poder gravar dados no buffer caso este no esteja cheio; Um processo s poder ler dados armazenados do buffer caso exista algum dado para ser lido; Em ambas as situaes, os processos devero aguardar at o buffer esteja pronto para as operaes, seja de gravao, seja de leitura. Os mecanismos que garantem a comunicao entre processos concorrentes e o acesso a recursos compartilhados so chamados mecanismos de sincronizao. No projeto de um SO multiprogramvel, fundamental a implementao destes mecanismos para garantir a integridade e a confiabilidade na execuo de aplicaes concorrentes.

3.Especificao de concorrncia em programas Existem varias notaes utilizadas para especificar a concorrncia em programas, ou seja, partes de um programa que devem ser executadas concorrentemente. A primeira notao para especificao da concorrncia em um programa foram os comandos FORK e JOIN. O exemplo a seguir apresenta a implementao da concorrncia: Program a; . . . FORK B; . . . JOIN B; . . END PROGRAM B; . . . . . . .END;

O programa A comea a ser executado e, ao encontrar o comando FORK, faz com que seja criado outro processo para a execuo do pgm B, concorrentemente ao programa A. O comando JOIN permite que o programa A sincronize-se com B, ou seja, quando o pgm A encontrar o JOIN, s continuar a ser processado aps o termino da execuo do pgm B. Os comandos FORK e JOIN so utilizados de forma semelhante no UNIX. Uma das implementaes mais claras e simples de expressar concorrncia em um programa a utilizao dos comandos PARBEGIN e PAREND. O comando PARBEGIN especifica que a seqncia de comandos seja executada concorrentemente em ordem imprevisvel, atravs da criao de um processo para cada comando. O comando PAREND define um ponto de sincronizao, onde o processamento s continuar quando todos os processos ou threads criados j estiverem terminado suas execues.

Um exemplo a seguir: PROGRAM expresso; Var x, t1,t2,t3:real; Begin PARBEGIN T1:=SQRT(1024); T2:=35.4 * 0.23; T3:=302/7; PAREND; X:=T1+T2-T3; WRITELN(X=,X); END.

4.Problemas de Compartilhamento de Recursos A primeira situao envolve o compartilhamento de um arquivo em disco: O programa contacorrente: PROGRAM CONTA_CORRENTE; . . READ(ARQ, REG_CLIENTE); READLN(VALOR_DEPOSITO); REG_CLIENTE.SALDO:=REG_CLIENTE.SALDO+VALOR_DEPOSITO; WRITE(ARQ,REG_CLIENTE); .. END. Considerando processos concorrentes pertencentes a dois funcionarios do banco que atualizam o saldo de um mesmo cliente simultaneamente. O processo do primeiro funcionrio l o registro do cliente e soma ao campo saldo o valor do dbito. Antes de gravar o novo saldo no arquivo, o processo do segundo funcionrio l o registro do mesmo cliente, que esta sendo atualizado, para realizar outro lanamento, desta vez de crdito. Independente de qual dos processos atualize primeiro o saldo no arquivo, o dado gravado estar inconsistente. caixa 1 1 1 2 2 2 1 2 comando Read Readln := Read Readln := Write Write saldo 1000 1000 1000 1000 1000 1000 800 1300 Valor deposito * -200 -200 * +300 +300 -200 +300 Saldo memria 1000 1000 800 1000 1000 1300 800 1300

5.EXCLUSAO MTUA A soluo mais simples para evitar os problemas de compartilhamento apresentados no item anterior impedir que dois ou mais processos acessem um mesmo recurso simultaneamente. Para isso, enquanto um processo estiver acessando determinado recurso, todos os demais processos que queiram acess-lo devero esperar pelo termino da utilizao do recurso. Essa idia de exclusividade de acesso chamada excluso mutua. Considere um sistema com muitos terminais em tempo compartilhado. Assuma que os usurios terminam cada linha de texto que eles digitam com a tecla <ENTER>. Suponha que seja desejvel monitorar continuamente o nmero total de linhas que os usurios entraram no sistema desde o incio do dia. Assuma que cada terminal de usurio seja monitorado por um processo diferente. Toda vez que um destes processos recebe uma linha do terminal, ele incrementa de 1 uma varivel global compartilhada do sistema, chamada LINHAS. Considere o que aconteceria se dois processos tentassem incrementar LINHAS simultaneamente. Assuma que cada processo possui sua prpria cpia do seguinte cdigo:
LOAD LINHAS ADD 1 STORE LINHAS ; L a varivel linhas no registrador acumulador ; Incrementa o registrador acumulador ; Armazena o contedo do acumulador na varivel

Suponhamos que LINHAS tenha o valor atual 21687. Agora suponhamos que o primeiro processo execute as instrues LOAD e ADD, deixando ento o valor 21688 no acumulador. Ento o processo perde o processador (aps o trmino de seu quantum) para o segundo processo. O segundo processo ento executa as trs instrues, fazendo com que a varivel linhas tenha o valor 21688. Ele ento perde o processador para o primeiro processo que continua executando de onde tinha parado, e portanto executando a instruo STORE, e armazenando 21688 na varivel LINHAS. Devido falta de comunicao entre os processos, o sistema deixou de contar uma linha o valor correto seria 21689. O problema est em dois ou mais processos escreverem em uma varivel compartilhada. Vrias processos poderiam estar lendo uma varivel compartilhada sem problemas. Entretanto, quando um processo l uma varivel que outro processo est escrevendo, ou quando um processo tenta escrever em uma varivel que outro processo tambm esteja escrevendo, resultados inesperados podem acontecer. O problema pode ser resolvido dando a cada processo acesso exclusivo varivel LINHAS. Enquanto um processo incrementa a varivel, todos os outros processos desejando faz-lo no mesmo instante devero esperar; quando o primeiro processo terminar o acesso varivel compartilhada, um dos processos passa a ter acesso varivel. Assim, cada processo acessando a varivel exclui todos outros de faz-lo simultaneamente. Isto chamado de excluso mtua. Como veremos, os processos em espera devero ser gerenciados de forma a esperarem um tempo razoavelmente curto.

5.1.Regies Crticas A excluso mtua deve afetar apenas os processos concorrentes somente quando um deles estiver fazendo acesso ao recurso compartilhado. A parte do cdigo do programa onde feito o acesso ao recurso compartilhado denominada regio critica. Se for possvel evitar que dois processos entrem mutuamente exclusiva das regies criticas, os problemas decorrentes do compartilhamento sero evitados. A excluso mtua somente precisa estar presente nos instantes em que os processos acessam dados compartilhados modificveis quando os processos esto executando operaes que no conflitam um com o outro, eles deveriam ser liberados para processarem concorrentemente. Quando um processo est acessando dados compartilhados modificveis, dito que o processo est em sua regio crtica ou seo crtica. Fica claro, que para evitarmos problemas como o mostrando acima, necessrio garantir que quando um processo est em sua regio crtica, todos os outros processos (pelo menos aqueles que acessam a mesma varivel compartilhada modificvel) sejam excludos de suas respectivas regies crticas. Enquanto um processo est em sua regio crtica, outros processos podem certamente continuar sua execuo fora de suas regies crticas. Quando um processo deixa sua regio crtica, um dos processos esperando para entrar em sua prpria regio crtica pode prosseguir. Garantir a excluso mtua um dos principais problemas em programao concorrente. Muitas solues foram propostas: algumas baseadas em software e outras baseadas em hardware; algumas em baixo nvel, outras em alto nvel; algumas requerendo cooperao voluntria entre processos, outras exigindo uma rgida aderncia a protocolos estritos. Um processo dentro de uma regio crtica est em um estado muito especial. O processo possui acesso exclusivo aos dados compartilhados modificveis, e todos os outros processos desejando acess-los devem esperar. Assim, regies crticas devem executar o mais rpido possvel, um processo no deve passar para o estado bloqueado dentro da regio crtica, e regies crticas devem ser cuidadosamente codificadas (para evitar, por exemplo, loops infinitos). 5.2.Solues de hardware A excluso muta pode ser implementada atravs de mecanismos de hardware. Neste item so apresentadas as solues de desabilitaro de interrupes e instrues test-and-set.

Instruo test-and-set Muitos processadores possuem uma instruo de maquina especial que permite ler uma varivel, armazenar seu contedo em uma outra rea e atribuir um novo valor a mesma varivel. Dessa forma, garantido que dois processos no manipulem uma varivel compartilhada ao mesmo tempo, possibilitando a implementao da excluso mtua. A instruo test-and-set possui o seguinte formato: Quando executada o valor lgico da varivel Y copiado para X, sendo atribudo a varivel Y o valor lgico verdadeiro. Test-and-set(x,y);