III - Processos e Threads

rocesso geralmente entendido como um programa em execuo porm, na realidade, trata-se de uma estrutura mais complexa que contm, alm do programa no seu formato executvel, todas as informaes necessrias (contexto) execuo e ao controle da execuo do mesmo, como por exemplo: o contador de programa, pilhas, registradores e rea de dados.

O programa uma entidade passiva, que pode ser visto como o contedo de um arquivo em disco, enquanto que o processo uma entidade ativa, possuindo um contador de programa (PC), que especifica a prxima instruo a ser executada, e um conjunto de recursos a ele alocados. Nos sistemas operacionais mais antigos, cada processo possuia um nico fluxo de controle, ou seja, as instrues so executadas seqencialmente, uma de cada vez. J nos sistemas mais modernos, um processo pode, por sua vez, dar incio a um ou mais subprocessos, que so executados em paralelo ou de forma concorrente com o processo pai e, para todos os efeitos, apresentam as mesmas caractersticas e particularidades de um processo qualquer, no tocante a contexto e fluxo de controle. Threads, por outro lado, representam uma nova concepo na forma de um processo paralelizar a execuo de partes do seu cdigo. Os threads, conceitualmente, se assemelham a subprocessos porm, diferentemente destes, no possuem identidade prpria e, portanto, no so independentes. Cada thread possui seu prprio contador de programa, sua pilha e seus registradores porm compartilham todos o mesmo espao de endereamento, isto , como se fossem uma nica entidade . Nos sistemas tradicionais, cada processo tem seu prprio contexto e apenas um fluxo de controle - so do tipo single thread. Freqentemente, no entanto, desejado ter-se mltiplos fluxos de controle que compartilhem do mesmo espao de endereamento e sejam executados de forma paralela (no caso de multiprocessamento) ou de forma concorrente (no caso de monoprocessamento), como se fossem processos separados. Threads satisfazem estes requisitos, pois compartilham do mesmo espao de endereamento com o processo pai e com os demais threads, e podem ser executados de forma concorrente ou paralela (fig. VIII.1). O esquema de threads, no entanto, s pode ser utilizado quando for especificamente suportado pelo sistema operacional ou quando da existncia de um gerenciador de threads. Os threads no so to independentes como os processos e os subprocessos, uma vez que compartilham de um mesmo espao de endereamento e, por conseguinte, compartilham das mesmas variveis globais, dos mesmos arquivos, das mesmas tabelas, etc. Uma vez que todo thread pode acessar todo o espao virtual de endereamento do processo pai e dos demais threads, ele pode ler e escrever em qualquer local, mesmo na pilha dos outros threads - o que significa que no h qualquer forma de proteo de acesso entre os threads. Os threads compartilham a UCP da mesma forma que os processos o fazem, isto , podem criar outros threads e podem ficar suspensos aguardando (em block waiting) pelo trmino de uma

Processos e Threads

39

operao qualquer (system call). Comparativamente, o contexto de um thread e de um processo constitudo por: Thread: Program Counter Stack (pilha) Conjunto de registradores Registrador de status Threads filhos Processo: Program Counter Stack Conjunto de registradores Registrador de status Espao prprio de endereo Variveis globais Arquivos abertos Semforos Informaes de contabilizao Processos filhos

Processo Y

P P P

Contexto do Sub-Processo A

Contexto do Sub-Processo B Contexto do Sub-Processo C

PC A B PC C PC

Processo X com 3 threads A, B, C

Figura VIII.1 - Processo Y com 3 subprocessos e Processo X com 3 Threads Cabe ao sistema operacional a incumbncia de prestar todo o suporte, os recursos e a proteo que forem necessrios execuo eficiente e eficaz dos processos que forem submetidos. Para isto, o SO precisa: a) ser capaz de alternar a execuo dos vrios processos submetidos de forma a maximizar o uso da UCP e ao mesmo tempo garantir um tempo de resposta razovel a cada processo;

40

Antonio G. Thom

Cap. VIII

b) distribuir os recursos

VIII.2 - Contexto de um Processo

O ambiente necessrio a execuo de um processo formado pelos contextos de hardware e de software. O contexto de hardware fundamental para que os processos possam se revezar no controle (utilizao) da UCP, podendo ser interrompidos pelo SO e, posteriormente, reinicializados do ponto onde haviam parado sem qualquer soluo de continuidade, isto , como se nada tivesse ocorrido. A operao que possibilita tal revezamento chamada de troca de contexto (context switch) e consiste basicamente em salvar o contedo dos registradores e carreg-los com os valores referentes ao processo que esteja ganhando o controle da UCP. O contexto de software especifica caractersticas do processo que influem na execuo do mesmo, tais como: o nmero mximo de arquivos abertos, o tamanho do buffer para operaes de E/S, etc. O Sistema Operacional cria para cada processo uma estrutura chamada PCB - Process Control Block, onde ele mantm todas as informaes de contexto (hardware e software) do processo. O contedo e a estrutura do PCB variam de sistema para sistema, sendo que no exemplo mostrado na figura VIII.2 a seguir, ele consiste do estado do processo, da sua identificao, do registrador PC, dos demais registradores da UCP, de informaes de escalonamento, de informaes de memria, de informaes de contabilizao e de informaes de entrada e sada. Ponteiro estado do processo identificao do processo registrador PC registradores da UCP informaes de escalonamento limites de memria informaes de contabilizao relao de arquivos abertos Figura VIII.2 - Exemplo de PCB - Process Control Block

VIII.3 - Estados de um Processo

O procedimento de execuo de um processo tem incio com a criao do mesmo, carga do mesmo em memria, para que de l possa ser escalado para tomar o controle da UCP e realizar seu processamento e, finalmente, terminado, quando da sua concluso. Quando em memria, o processo pode estar num dos trs estados seguintes: em execuo, em espera pela ocorrncia de um evento previamente solicitado por ele mesmo ou, no estado de pronto para execuo. Estados estes representados na figura VIII.3.

Processos e Threads

41

Um processo para poder ser escalado para execuo precisa estar no estado de pronto (ready). Um processo em execuo pode perder o controle da UCP de forma voluntria (quando ele prprio realiza uma operao de E/S) ou de forma involuntria (quando por algum critrio gerencial o prprio sistema operacional retoma o controle da UCP). Um processo em estado de espera fica nesta situao at que sua pendncia seja satisfeita e de l passa para o estado de pronto.
concludo terminado novo interrompido execuo suspenso escalado admitido pronto espera atendido

Figura VIII.3 - Estados de um Processo Quando um processo em execuo solicita um recurso que no est disponvel no momento (como por exemplo a alocao de um arquivo ou de um perifrico) ou cuja obteno seja operacionalizada fora da UCP (como por exemplo leitura de registros em disco - DMA), ele automticamente perde o controle da UCP e passa do estado de execuo para o de espera. O processo estando no estado de espera passa para o estado de pronto para execuo assim que tiver sua solicitao de recurso atendida pelo sistema. No estado de pronto ele est em condies de reiniciar sua execuo e fica aguardando apenas chegar sua vez de retomar o controle da UCP. Nos sistemas preemptivos, isto , que admitem interromper a execuo de um processo toda vez que seu tempo (quantum) permitido para alocao da UCP expirar, pode ocorrer que um processo saia da UCP no para o estado de espera mas direto para o estado de pronto. V-se assim que um processo pode mudar de estado face um evento originado por ele prprio (eventos voluntrios) ou pelo sistema (eventos involuntrios).

VIII.3.1 - Estados de Execuo de um Processo

Dentro do estado de execuo, para fins de proteo do sistema como um todo, so adotados nveis de prioridade que definem o que o processo est ou no autorizado a fazer. a forma utilizada para evitar que processos dos usurios venham a danificar reas do sistema operacional ou mesmo reas reservadas a outros processos. Diversas so as estratgias de definio destes nveis de prioridade. A estratgia bsica consiste na definio de dois estados, um supervisor e outro usurio. Sistemas mais complexos como o OS/2 por exemplo, adotam 4 nveis: 0 - kernel (supervisor), 1 - sistema de arquivos, comunicao entre processos e acionadores de dispositivos de E/S, 2 - subsistema de E/S e 3 - usurio. Um processo somente passa de um nvel superior para um inferior com autorizao do sistema operacional, que assim garante a integridade operacional.

42

Antonio G. Thom

Cap. VIII

VIII.4 - Sincronizao de Processos

O compartilhamento de recursos entre processos pode gerar situaes indesejveis de inconsistncia no acesso aos dados e de indisponibilidade no acesso aos recursos, a ponto de comprometer o sistema como um todo. A soluo para estes casos garantir a excluso mtua, isto , apenas um processo tem autorizao para acessar o recurso de cada vez. O trecho do programa onde feito o acesso ao recurso compartilhado denominado regio crtica e os mecanismos que implementam a excluso mtua utilizam um protocolo de acesso regio crtica. Toda vez que um processo for executar sua regio crtica, ele obrigado a passar por um controle de entrada e outro de sada.

VIII.4.1 - Problemas de Sincronizao

Surgem a partir das tentativas de implementar a excluso mtua. a) velocidade de execuo dos processos A velocidade de execuo dos processos pode interferir na operacionalizao da excluso mtua. No caso de um chaveamento simples entre dois processos, digamos A e B, sendo que o processo A consome um tempo de processamento bem mais longo que o processo B, pode levar a situao em que B se veja impossibilitado de entrar em sua regio crtica por estar bloqueado pela execuo do processo A fora da sua regio crtica (fig. VIII.4).

Prog A vez = A
regio crtica vez = B

Prog B vez = B
regio crtica vez = A

Processamento longo

Processamento curto

Figura VIII.4 - Prog B impedido de acessar sua regio crtica porque Prog A detm o controle da UCP em longo processamento fora da sua regio crtica. Observe na figura que o programa "B" passa pela sua regio crtica e em seguida libera o acesso ao programa "A". Caso o programa "B" retorne ao ponto de entrada de sua regio crtica antes que o programa "A" passe por sua regio crtica e libere o acesso ao programa "B", este ficar bloqueado embora o programa "A" no esteja usando sua regio crtica. b) Starvation

Processos e Threads

43

a situao onde um processo nunca consegue executar sua regio crtica e, em conseqncia, nunca consegue acessar o recurso compartilhado. Este problema ocorre quando 2 ou mais processos esto na lista de espera por um recurso compartilhado. No momento em que o recurso liberado, o sistema precisa determinar qual dos processos em espera deve ganhar acesso ao recurso. Esta escolha pode ser: aleatria - um processo pode nunca ser escolhido e sofrer starvation; por prioridade - um processo pode novamente permanecer indefinidamente na fila de espera face a constante chegada de processos de maior prioridade; fila tipo FIFO - evita starvation porm pode prejudicar o desempenho de programas com maior prioridade de execuo. c) Sincronizao Condicional quando um recurso compartilhado no se encontra pronto para ser utilizado e, nesse caso, o processo precisa ser mantido em estado de espera at o recurso ficar pronto. Este tipo de sincronizao aparece em qualquer operao onde existam processos gerando servios e processos consumindo estes mesmos servios. Um exemplo clssico deste tipo de sincronizao o da gravao de um buffer por um processo e leitura por outro. Ambos os processos envolvidos devem ser sincronizados de forma a no tentarem gravar um buffer cheio ou ler um buffer vazio.

VIII.4.2 - Solues de Hardware

a) desabilitao de interrupes Como a mudana de contexto s pode ser realizada atravs do uso de interrupo, se um processo desabilitar suas interrupes internas ao entrar na sua regio crtica, ele garantir a excluso mtua porque no poder ser interrompido pelo sistema. Este mecanismo no entanto, no dos mais convenientes por vrios motivos, sendo que os principais so: o processo no tornar a habilitar suas interrupes ao sair da regio crtica, permanecer com o controle da UCP at que ele a deixe por um evento voluntrio. o processo entrar em loop dentro da regio crtica e, novamente, ningum o interromper. Desabilitar interrupes uma soluo interessante porm face ao potencial de efeitos colaterais que possam surgir, normalmente adotado apenas pelas rotinas do sistema operacional. b) instruo test-and-set uma instruo atmica - indivisvel e que no pode ser interropida pela UCP - que testa e seta uma varivel global que serve de senha de acesso a uma regio crtica. test-and-set(X,Y)

44

Antonio G. Thom

Cap. VIII

X Y Y TRUE end ex. de utilizao: repeat pode_a:= True; while (pode_a) do test-and-set(pode_a,bloqueio); : regio crtica : bloqueio:= False; until (pode_a)

VIII.4.3 - Solues de Software

Trs fatores fundamentais para a soluo dos problemas de sincronizao devem ser considerados: 1. o nmero de processos concorrentes e o tempo de execuo dos mesmos devem ser irrelevante; 2. um processo fora de sua regio crtica no deve impedir que outros processos entrem em suas prprias regies crticas; 3. um processo no pode permanecer indefinidamente esperando para entrar na sua regio crtica (starvation); As solues inicialmente implementadas para resolver o problema de excluso mtua sofriam da sndrome do busy waiting, ou seja, o processo permanecia em loop checando a liberao do acesso regio crtica e, portanto consumindo cilcos de UCP. As solues mais atuais adotam primitivas que permitem que um processo seja colocado em estado de espera e reativado apenas quando o recurso estiver disponvel. Nesta linha foram introduzidos os semforos e os monitores. a) Semforo Consiste em uma varivel inteira, no negativa, que s pode ser manipulada por duas instrues atmicas: down e up. Cada semforo associado a um nico recurso compartilhado e seu significado : 0 >0 inexistncia de recurso disponvel; dispolibilidade de recurso.

Um processo para entrar em sua regio crtica precisa antes decrementar o contedo do semforo (down), que s permitido se ele for >0 e ao sair incrementa-o (up), liberando o recurso para os demais processos. Up e Down so atmicas e geralmente implementadas como system calls. Quando o processo executa um down em um semforo vazio, ele automaticamente colocado em estado de espera (sleeping) e automaticamente reativado quando algum outro processo liberar (up) aquele recurso.

Processos e Threads

45

exemplo, semforo para o caso do produtor-consumidor #define N 100 typedef int semaphore; semaphore mutex = 1; semaphore empty = N; semaphore full = 0; void produtor(void) { int item; while (TRUE) { /* loop infinito */ produce_item(&item); /* produz alguma coisa para colocar no buffer */ down(&empty); /* verifica se h buffer disponvel */ down(mutex); /* testa entrada na regio crtica */ enter_item(item); /* coloca dado no buffer */ up(&mutex); /* libera o recurso */ up(&full); /* indica colocao de dado no buffer */ } } void consumidor (void) { int item; while (TRUE) { down(&full); down(&mutex); remove_item(&item); up(&mutex); up(&empty); consume_item(item); } } /* define o tamanho do buffer */ /* semforos sero um tipo especial de inteiros */ /* controla o acesso a regio crtica */ /* controla a quantidade de buffer disponvel */ /* controla a quantidade de buffer em uso */

/* verifica existncia de dado no buffer */ /* testa entrada na regio crtica */ /* pega dado do buffer */ /* libera o recurso */ /* acusa retirada de um dado do buffer */ /* consome o dado */

b) Monitor O uso de semforos exige muito cuidado do programador pois qualquer engano pode levar a problemas de sincronizao imprevisveis e difceis de reproduzir, face execuo concorrente dos processos. Monitores so mecanismos de alto nvel implementados pelo prprio compilador. Para isto basta especificar todas as regies crticas em forma de procedimentos do monitor, e o compilador se encarregar de implementar a excluso mtua.

46

Antonio G. Thom

Cap. VIII

VIII.4.4 - Deadlock
conseqncia do compartilhamento exclusivo e ocorre sempre que um ou mais processos estiverem esperando por um evento (recurso) que jamais ocorrer. Caracteriza-se por uma espera circular onde dois ou mais processos aguardam pela liberao de recursos para que possam continuar suas tarefas. Exemplo, o processo "A", da figura VIII.5, detm o recurso X e espera pelo recurso Y, por outro lado, o processo "B" detm o recurso Y e espera pelo X.

Proc. A Recurso X

Proc. B Recurso Y

Figura VIII.6 - Esquema representativo de um Deadlock a) condies para ocorrncia de deadlock cada recurso s pode estar alocado a um nico processo em um determinado instante (excluso mtua); um processo, alm dos recursos j alocados, pode ficar na espera por outros; um recurso no pode ser retirado de um processo porque outros processos o esto desejando (no-preempo); um processo pode aguardar por um recurso que esteja alocado a outro processo e viceversa (espera circular). Dois procedimentos podem ser implementados para tratamento de deadlocks: previnir sua ocorrncia ou, detetar sua ocorrncia.

a.1) preveno de deadlocks Constitui-se de aes a serem tomadas com o objetivo de previnir a ocorrncia de uma ou mais situaes que possam levar ao surgimento de um de deadlock. Algumas possibilidades so: estabelecer o critrio de que todos os recursos sejam previamente alocados, antes do processo ganhar acesso UCP; admitir a prtica da preempo, isto , o sistema ter a possibilidade de retirar um recurso alocado para um processo e dar para outro processo; forar que um processo no aloque mais do que um recurso de cada vez. Qualquer que seja a estratgia de preveno adotada, ela sempre muito onerosa, uma vez que precisa ser executada a todo instante. A estratgia mais comum e menos onerosa detectar a ocorrncia de um deadlock e, uma vez detectado, executar rotinas de resoluo do problema. a.2) Deteco de Deadlocks

Processos e Threads

47

Geralmente os algoritmos que implementam este mecanismo verificam a existncia de uma espera circular, percorrendo toda a estrutura de alocao sempre que um processo no pode ser imediatamente atendido. Aps o deadlock ser detectado, as aes de correo mais comuns so: eliminar um ou mais processos envolvidos; liberar acumulativamente alguns dos recursos j alocados pelos processos envolvidos at que a espera circular se desfaa.

VIII.5 Escalonamento de Processos

Os principais objetivos do escalonamento (scheduling) de processos so: manter a UCP ocupada a maior parte do tempo; balancear a utilizao do processador pelos processos em execuo; maximizar o throughput (capacidade de atendimento a processos) do sistema; e garantir tempos de resposta razoveis aos usurios interativos. Para atender tais objetivos, muitas vezes conflitantes, os SOs precisam levar em considerao: as caractersticas dos processos em execuo (batch, interativo, tempo-real, CPUbounded, IO_bounded); a disponibilidade de recursos; as caractersticas da instalao. O escalonamento dos processos realizado por um mdulo do sistema operacional conhecido como dispatcher (scheduler). Existem diversos algoritmos utilizados para tal finalidade e cada um apresenta caractersticas prprias favorecendo um ou outro critrio para a escolha do prximo processo a receber o controle da UCP. Os critrios geralmente considerados incluem os seguintes parmetros ou medidas de eficincia: utilizao da UCP - o desejado manter a UCP p mais ocupada possvel. O grau de utilizao da UCP varia de 0 (idle) a 100%. Geralmente a ocupao da UCP gira no entorno dos 40% para sistemas com carga moderada e aproximadamente 90% para os com carga pesada. throughput - medida que representa o nmero de processos concludos por unidade de tempo (ex. 10 processos/segundo). turnaround time - mede o tempo total gasto na execuo de um processo, desde o momento em que ele submetido at o instante em que concludo. waiting time - mede apenas o tempo em que o processo fica aguardando por execuo na fila de processos prontos (ready queue). response time - mede o tempo decorrido entre a submisso do processo e o instante em que o mesmo gera a primeira resposta ao usurio. Existem basicamente dois tipos de algoritmos para escalonamento de processos: os do tipo preemptivo e os do tipo no-preemptivo.

48

Antonio G. Thom

Cap. VIII

VIII.5.1 - Algoritmos No-Preemptivos

Nesse tipo de escalonamento, quando um processo ganha o direito de utilizar a UCP, nenhum outro processo ou mesmo o prprio SO pode lhe tirar esse recurso. Ele manter o uso da UCP at que, voluntariamente, a deixe. Dentro do contexto dos algoritmos no-preemptivos, diferentes estratgias podem ser implementadas, tais como: o escalonamento FIFO e o shortest_job_first.

a) Escalonamento FIFO de implementao e operao bastante simples, necessitando apenas da manuteno de um fila, onde os processos que passam para o estado de pronto entram no final da mesma e so escalados para execuo quando atingem o seu topo. As maiores restries relativas a esta estratgia so: incapacidade de prever o instante inicial de execuo de um processo; possibilidade de ocorrncia de processos CPU_bound de menor importncia prejudicarem o processamento de processos IO_bound mais prioritrios; Esta estratgia no eficiente para sistemas de tempo compartilhado e muito menos para sistemas em tempo real.

b) Escalonamento Shortest_Job_First Associa a cada processo uma estimativa do seu tempo de execuo e favorece aqueles de menor tempo, escalando-os prioritariamente. A restrio maior deste algoritmo est na determinao da estimativa do tempo necessrio para execuo de um determinado processo. Tarefa fcil para processos (sistemas) j em regime de produo mas extremamente difcil para aqueles ainda em fase de desenvolvimento.

VIII.5.2 - Algoritmos Preemptivos

Um algoritmo de escalonamento considerado preemptivo quando pode interromper um processo em execuo, tirar-lhe o controle da UCP e repassla para outro processo que estiver na fila de espera. A estratgia preemptiva permite que o sistema d ateno imediata a processos mais prioritrios, bem como o compartilhamento do processador de forma mais uniforme. importante lembrar que a troca de um processo na UCP implica, necessariamente, na troca de contexto (context switching), o que representa um overhead introduzido pelos algoritmos pre-

Processos e Threads

49

emptivos no existente na estratgia no-preemptiva. Para que isto no se torne um problema crtico, os parmetros de quantum ou time slice adotados para os processos em execuo precisam ser cuidadosamente estabelecidos. Os principais algoritmos deste genero incluem: o round_robin, o por prioridade, o por mltiplas filas e o por mltiplas filas com realimentao.

a) Escalonamento Round_Robin um escalonamento circular, bastante similar ao FIFO, porm com a adoo de um limite de tempo (quantum ou time_slice) permitido aos processos para uso contnuo da UCP. A definio deste quantum um parmetro de gerncia da operao, sendo que se deve levar em considerao a disponibilidade de recursos (MP e processador), o tipo e o nmero de processos em execuo. Um tamanho razovel para este quantum pode oscilar, por exemplo, entre 100 e 300ms. b) Escalonamento Baseado em Prioridade O escalonamento leva em considerao o nvel de prioridade estabelecido para os processos. importante observar que contrariamente ao que possa ser inicialmente imaginado, os processos do tipo IO_bound devem, em princpio, receber uma prioridade mais alta, a fim de compensar o excessivo tempo gasto no estado de espera. O nvel de prioridade uma caracterstica do processo e pode ser dos tipos esttica ou dinmica. Na prioridade dinmica, ela pode ser constantemente ajustada em funo do tipo de processo e da carga corrente do sistema.

c) Escalonamento por Mltiplas Filas Como os diversos processos em execuo geralmente possuem caractersticas de processamento distintas, difcil imaginar que um nico mecanismo de escalonamento seja igualmente adequado a todos. Uma boa poltica seria a de classificar os processos em funo do tipo de processamento realizado, e aplicar a cada grupo um mecanismo distinto de escalonamento. O escalonamento por mltiplas filas implementa diversas filas de processos no estado de pronto (ready), e a cada fila pode ser estabelecido um mecanismo de escalonamento diferente. Cada fila possui uma prioridade associada, que estabelece uma relao de prioridade entre elas e o sistema, a partir disto, somente escala processos de uma fila quando todas as outras de maior prioridade estiverem vazias.

d) Escalonamento por Mltiplas Filas com Realimentao Estratgia que visa reduzir a penalidade imposta pelo mtodo anterior aos processos classificados em filas de mais baixa prioridade. Visa tambm atenuar injustias que podem se materializar no mtodo por mltiplas filas pelo fato de um processo alterar seu comportamento no decorrer do seu processamento.

50

Antonio G. Thom

Cap. VIII

Nesta estratgia de escalonamento, o sistema tenta identificar dinamicamente o comportamento de cada processo durante seu perodo de execuo, e ajustar tambm dinamicamente, a prioridade e o mecanismo de escalonamento associado a cada um. A figura abaixo mostra um esquema com m filas e diferentes estratgias. Um processo ao ser inicializado (startado) colocado no final da fila correspondente ao seu nvel de prioridade. Sua progresso dentro da fila segue a estratgia de escalonamento ali adotada e, aps ter sido escalado e concludo sua etapa de processamento, ele volta para o fianl da fila imediatamente inferior, caso sua perda da UCP tenha ocorrido por preempo ou no final da fila imediatamente superior, caso a perda da UCP tenha ocorrido voluntariamente para espera da ocorrncia de algum evento externo.

Maior Priori-

FILA #1 - (Por Prioridade) Sada por FILA #2 - (Por Prioridade) Sada por FILA #3 - (Por Prioridade)

Menor Quan-

Sada por FILA #m - (Round Robin) Menor PrioriMaior Quan-

Figura VIII.7 - Esquema de Escalonamento por Mltiplas Filas com Realimentao

VIII.6 Exerccios
1) Das afirmativas abaixo, aquela que contraria o conceito de interrupo : a. o controle da UCP interrompe o programa em execuo e vai para a instruo seguinte da rotina de tratamento especfica da interrupo em questo. b. o estado corrente da UCP precisa ser previamente salvo, para que seja dado incio ao tratamento da interrupo. c. o endereo inicial da rotina de tratamento da interrupo determinado pelo Hardware. d. um sinal de Hardware interno ou externo UCP pode dar incio a uma interrupo. e. uma rotina de tratamento de interrupo tambm pode ser interrompida e dar lugar a execuo de uma outra rotina de tratamento.

Processos e Threads

51

2) Conceitue deadlock e explique as estratgias de preveno e deteco. 3) Conceitue e diferencie Processo e Thread. 4) Conceitue sincronizao de processos e descreva duas tcnicas de realizao. 5) No diagrama abaixo, que representa os estados possveis de um processo em execuo: Running

Ready

Wait

A transferncia de um processo para o estado "ready" ocorre sempre que: a. ele realiza um "page fault" b. atinge seu quantum permitido de UCP c. precisa efetuar uma operao de E/S d. entra em deadlock e. realiza um DMA 6) Em termos de escalonamento de processos, conceitue preempo e quantum ou time-slice. 7) Suponha que um sistema operacional do tipo preemptivo multiprogramvel seja carregado com trs mdulos executveis identificados por A, B e C. O processo A, inicialmente em estado ready, tem prioridade inicial mxima (10), perde 2 pontos a cada vez que sofre uma interrupo por I/O, possui time-slice de 1seg e sofre 2 interrupes de 1 seg cada aps os 2 e 3 segundos de processamento. O processo B, inicialmente em ready, tem prioridade inicial 8, time-slice de 2 segs e no perde prioridade por ser um processo em tempo real. O processo C, inicialmente em wait e sendo processo de menor prioridade, entra em ready 3 segs aps sua submisso. Sabendo-se que B solicita um I/O de 3 segs aps 4 segs de execuo e que A, B e C consomem respectivamente um total de 5, 6 e 5 segs de processamento, calcule o instante em que os processos terminaro sua execuo (turnaround time) e o throughput do sistema. 8) Em um determinado sistema multiprogramado 5 jobs, J1, J2, J3, J4 e J5 (conforme tabela abaixo) concorrem pelo controle da UCP. Considerando que todos esto na condio ready e assumindo 3 hipteses de escalonamento: FCFS, prioridade no-preemptiva e shortest_job_first, responda s seguintes perguntas: Job 1 2 3 4 5
a)

Tempo de execuo 10 1 2 1 5

Prioridade 3 0 2 4 1

qual o turnaround de cada processo segundo cada um dos mtodos de escalonamento?

52 b)

Antonio G. Thom

Cap. VIII

qual o mtodo de escalonamento que apresenta o melhor throughput para o sistema? c) qual o turnaround dos processos admitindo um quantum de 2 unidades de tempo para os mtodos de escalonamento por prioridade e round_robin? 9) Considere que um determinado SO no possua memria suficiente e que para fazer task switch (troca de tarefas), precise realizar swapping em disco. Calcule o tempo gasto para efetuar a troca de 2 tarefas de 50KB cada, no caso em que a unidade de disco apresenta as seguintes caractersticas: capacidade de 1.28GB, taxa de transferncia de 5MBs, seek mdio de 10ms e latncia rotacional de 50ms. 10) Os mecanismos que garantem a comunicao entre processos e o compartilhamento de recursos do sistema, so chamados de mecanismos de a) sincronizao b) concorrncia c) paginao d) segmentao e) realimentao

VIII.7 Referncias Bibliogrficas

Tanenbaum, Andrew S., Organizao Estruturada de Computadores, Ed. Prentice-Hall do Brasil, 1990. Tanenbaum, Andrew S., Sistemas Operacionais - Projeto e Implementao, Ed. Prentice-Hall do Brasil, 1987. Machado, Francis B. e Maia, Luiz P., Introduo Arquitetura de Sistemas Operacionais, Ed. LTC, 1994. Tanenbaum, Andrew S., Sistemas Operacionais Modernos, Ed. Campus, 1995. Davis, William S., Sistemas Operacionais - Uma Viso Sistemtica, Ed. Campus, 1990.