Arquitetura de Sistemas Operativoshpcosta/so/soMod5BAula4.1.pdf · 2012-04-17 · TGPSI 09/12...

! Prof. Hernani

Resumo Mecanismos de Sincronismo

Arquitetura de Sistemas Operativos

Hernani Costa

[email protected]

Sistemas Operativos 2011/2012

Hernani Costa [email protected]

TGPSI 09/12 Sistemas Operativos Modulo 5

[email protected]

! Prof. Hernani


1 Mecanismos de SincronismoSeccoes Crıticas



[email protected]

! Prof. Hernani


Seccoes Crıticas

Necessidade das Seccoes Crıticas

As tarefas que se executam em paralelo nao sao normalmenteindependentes, tendo de se sincronizar para poderem executarum algoritmo global comum.

Existem diversos motivos que justificam a necessidade desincronizar explicitamente essas tarefas.

Para simplificar a sua analise agrupamo-los em duascategorias: competicao de varias tarefas por um determinadorecurso e cooperacao entre tarefas.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Considere-se o exemplo seguinte: uma conta bancaria a quevarias tarefas pretendem aceder ou atualizar.

O codigo seguinte mostra uma funcao em linguagem C, quepoderia fazer parte de um programa que permite efetuarvarias operacoes de ındole bancaria.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Funcao que permite levantar dinheiro de uma contabancaria

struct {int saldo;

} conta t;

int levantar dinheiro (conta t* conta, int valor) {if (conta –> saldo >= valor)

conta –> saldo = conta –> saldo - valor;

else

valor = -1; /* -1 indica erro ocorrido */

return valor;

}



[email protected]

! Prof. Hernani


Seccoes Crıticas

Esta funcao suporta uma funcionalidade similar a queencontramos disponibilizada nas maquinas multibanco:levantar dinheiro.

Na realidade, os sistemas bancarios nao funcionam destaforma, mas poderıamos conceptualmente considerar queexistia um servidor no banco que executava os pedidos vindosde uma maquina multibanco e que, a cada pedido, dedicavauma tarefa de modo a suportar paralelismo no atendimento.

Os servidores bancarios seriam assim implementados de formaa servir os pedidos efetuados pelas maquinas multibanco emparalelo, portanto, o codigo em causa seria executado porvarias tarefas concorrentemente.



[email protected]

! Prof. Hernani


Seccoes Crıticas

A operacao descrita na funcao anterior permite efetuar umdebito, no valor indicado pelo segundo argumento da funcao,numa conta identificada pelo primeiro argumento (referenciapara uma zona de memoria do tipo conta t).

O objeto referenciado pelo argumento conta tem um campodenominado saldo cujo valor corresponde ao saldo da contaem causa.

Considerando a funcao numa optica de programacaosequencial, esta nao tem qualquer erro.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Obviamente, e crucial que todas as operacoes bancarias sejamefetuadas de modo a que seja assegurada a sua consistenciaem termos financeiros.

Como o programa e concorrente, o que se pretende e que,apesar de existirem varias tarefas, o funcionamento do sistemaseja equivalente ao que se obteria caso as tarefas seexecutassem sequencialmente.

Em particular, nao devera ocorrer, em nenhuma circunstancia,uma situacao em que seja permitido efetuar debitos naocontabilizados ou para os quais nao haja saldo disponıvel.

Vamos ver um exemplo onde tal sucede.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Suponhamos que existe uma conta solidaria com doismembros que a podem movimentar livremente e que ambostentam ao mesmo tempo, em maquinas multibanco distintas,levantar uma determinada quantia de dinheiro.

Portanto, a referida funcao e invocada concorrentemente porduas tarefas (dentro do processo servidor bancario) em quecada uma serve um pedido de debito sobre a mesma conta.

Numa observacao menos atenta podemos ser levados aconcluir que nao ha nenhum problema resultante destasituacao, no entanto, uma observacao mais cuidada leva-nos aconclusao oposta.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Com efeito, considerando que neste exemplo temos duastarefas que executam o codigo em causa, e que o codigo if (... ) .. else ... corresponde de facto a varias instrucoes quesao executadas de forma sequencial pelo processador, podesuceder a situacao ilustrada na figura seguinte que apresenta aevolucao temporal das instrucoes executadas pelas duastarefas.



[email protected]

! Prof. Hernani


Seccoes Crıticas



[email protected]

! Prof. Hernani


Seccoes Crıticas

A tarefa T2 executou o codigo da funcao levantar dinheiro deforma intercalada com a tarefa T1.

Como se pode observar, esta comutacao de tarefas ocorre detal forma que, logo apos o teste efetuado por T1, esta perde oprocessador para T2.

A instrucao que T1 executa como resultado do teste so e defacto executada depois de T2 ter executado, na totalidade, afuncao levantar dinheiro, ou seja, como T1 tinha efetuado oteste, nao o vai repetir quando o despacho a selecionarnovamente, uma vez que o program counter ja referencia ainstrucao seguinte.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Nestas circunstancias, assumindo que o saldo inicial tinha ovalor 100 e que as duas operacoes de levantamentopretendiam retirar da conta respectivamente 30 por T1 e 90por T2, o que sucederia e que no teste inicial de T1,100>=30 era verdadeiro, em seguida na tarefa T2 o testetambem era valido porque 100>=90 uma vez que o valor dosaldo nao tinha sido subtraıdo da quantia a levantar em T1.

No final o valor do saldo da conta em causa seria:100 - 30 - 90 = -20

Portanto, teria sido permitido um levantamento sem quehouvesse cobertura para tal.



[email protected]

! Prof. Hernani


Seccoes Crıticas

A primeira vista, esta situacao de intercalacao das tarefas T1e T2 pode parecer forcada: T1 perde o processadorimediatamente apos ter efetuado o testeif (conta>saldo>=valor) e antes de executar a instrucaoseguinte.

No entanto, isso nao e verdade por duas razoes:

Primeiro, na aplicacao em causa teremos inumeras execucoesdesta funcao pelo que a probabilidade de vir a acontecer areferida intercalacao e relevante.

Segundo, cada instrucao na linguagem C resulta, de facto, emvarias instrucoes maquina executadas pelo processador.



[email protected]

! Prof. Hernani


Seccoes Crıticas

A razao que esta na base deste funcionamento erroneo e ofacto de estarmos a considerar um sistema operativomultiprogramado – no qual e perfeitamente possıvel que atarefa T1 perca o processador (e.g., o seu time-sliceesgotou-se), a meio da funcao em causa e, que a tarefa T2seja, em seguida, escalonada pelo sistema operativo.

O erro existe porque o bloco de codigo deveria ser executadona sua totalidade pela tarefa T1 e so depois pela tarefa T2(ou vice-versa) uma vez que ambas acedem a mesma conta.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Ou seja, as instrucoes deveriam ser executadas em exclusaomutua ou, dito de outra maneira, de forma indivisıvel ouatomica.

O bloco de codigo em causa e entao designado como umaseccao crıtica.



[email protected]

! Prof. Hernani


Seccoes Crıticas

De uma forma geral, o problema apresentado ocorre quandouma tarefa testa uma variavel e, em funcao do seu valor,decide ou nao modifica-la.

Pode suceder que outra tarefa, que entretanto se executaconcorrentemente, decida tambem testa-la.

A execucao do programa torna-se incoerente dado quesucedeu algo nao previsto no modelo de programacaosequencial pois a variavel mudou de valor, depois do teste,atraves de uma acao exterior.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Para que fique claro este aspeto fundamental da sincronizacao,e apresentado em seguida um segundo exemplo que nos vaipermitir ilustrar diversos conceitos de sincronizacao.

Consideremos um alocador de memoria (programa parareservar blocos de memoria) muito simples num sistemaconcorrente.

As tarefas que pretendam reservar memoria invocam asfuncoes deste alocador.



[email protected]

! Prof. Hernani


Seccoes Crıticas

O algoritmo de atribuicao de blocos de memoria e suportadopor uma estrutura de dados implementada por uma pilha.

Os elementos da pilha indicam o endereco inicial do bloco dememoria.

Para simplificar o algoritmo, vamos supor:

que todos os blocos sao identicos, com um tamanho definidoinicialmente;as tarefas apenas podem pedir blocos completos, nao fazendoo sistema qualquer subdivisao dos blocos.

O codigo na linguagem C correspondente a este alocador dememoria e apresentado de seguida.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Funcoes de um alocador de memoria simplificado

#define MAX PILHA 100

char* pilha [MAX PILHA];

int topo = MAX PILHA - 1;

char* PedeMem () {ptr = pilha[topo];

topo −−;

return ptr;

}

void DevolveMem (char* ptr) {topo++;

pilha[topo]= ptr;

}



[email protected]

! Prof. Hernani


Seccoes Crıticas

Para pedir um bloco de memoria, uma tarefa executa afuncao PedeMem que tem como parametro de saıda oapontador para o bloco de memoria.

Para devolver a zona de memoria ao alocador, chama afuncao DevolveMem.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Como foi referido anteriormente, a estrutura de dados e umapilha implementada da forma mais simples:

atraves de um vector de apontadores indexado por umavariavel que referencia o apontador para o proximo bloco dememoria a atribuir.

Pilha e topo sao variaveis globais do programa alocador dememoria, que sao convenientemente inicializadas no inıcio daexecucao.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Aparentemente, a estrutura anterior funciona de acordo com oobjetivo pretendido.

Contudo, se analisarmos com maior detalhe o programa,detetamos novamente problemas resultantes da concorrenciaentre as diversas tarefas.

Com efeito, suponhamos que uma tarefa T1 inicia a devolucaode memoria mas, devido a uma interrupcao, e-lhe retirado oprocessador (e.g., imediatamente apos a instrucao topo++).



[email protected]

! Prof. Hernani


Seccoes Crıticas

Consideremos que a tarefa T2 que se executa em seguidapretende pedir memoria.

Neste caso somos conduzidos a uma situacao que originaraum erro no funcionamento do sistema:

o endereco do bloco de memoria que a tarefa T2 obtem einvalido;a tarefa T1 apenas tinha incrementado a variavel topo e naotinha ainda actualizado o apontador que ela passou areferenciar;o apontador que estara no bloco pode ser invalido oucorresponder a um bloco de memoria que foi atribuıdo a outratarefa anteriormente.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Outras situacoes de potencial erro aparecem na funcaoPedeMem se for interrompida antes de decrementar a variaveltopo.

Estes exemplos podem parecer forcados, pois pressupoem umacerta sequencia de acontecimentos.



[email protected]

! Prof. Hernani


Seccoes Crıticas

No entanto, e preciso considerar que as operacoes em causa(e.g., levantar dinheiro ou pedir e devolver memoria):

podem ser executadas milhoes de vezes no decorrer da vida deum sistema e que,mesmo para um encadeamento da execucao das tarefas compequena probabilidade, existe a possibilidade de ela vir averificar-se, reforcado pelo facto de as interrupcoes queprovocam a comutacao das tarefas serem servidas depois dequalquer instrucao maquina e nao depois das instrucoes de C.



[email protected]

! Prof. Hernani


Seccoes Crıticas

E ainda de considerar que um erro deste tipo pode ter umacaraterıstica aparentemente aleatoria (aparece de tempos atempos), o que o torna extremamente difıcil de detetar.

Esta aleatoriedade esta na base da denominacao destes erroscomo Heisenbugs1, por analogia com o princıpio da incertezade Heisenberg.

1http://en.wikipedia.org/wiki/Heisenbug



http://en.wikipedia.org/wiki/Heisenbug

[email protected]

! Prof. Hernani


Seccoes Crıticas

E importante identificar claramente a origem dos erros que severificam nos exemplos anteriores.

No que diz respeito ao exemplo do alocador de memoria, atarefa T2 utiliza um apontador de memoria que nao e valido,porque o valor da variavel topo nao esta coerente com oestado da tabela pilha.

As duas variaveis representam o estado global do alocador dememoria e a sua modificacao nao foi feita de forma atomica,conduzindo a que o estado da pilha seja incoerente.

Estas variaveis tem de ser atualizadas em conjunto, nao sepodendo permitir atualizacoes parciais.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Em conclusao, em programacao concorrente sempre que setesta e se modifica estruturas de dados partilhadas (umasimples variavel, tabelas ou estruturas dinamicas) e necessariogarantir que as operacoes sao executadas dentro de umaseccao crıtica.

Esta caraterıstica tem a ver com o mecanismo de base desuporte a multiprogramacao e, portanto, e intrınseca a todosos sistemas operativos.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Em programacao concorrente sempre que se testam ou semodificam estruturas de dados partilhados e necessarioefetua-lo dentro de uma seccao crıtica.



[email protected]

! Prof. Hernani


Seccoes Crıticas

Avaliacao - Trabalho Teorico-Pratico 9

Escreve um pequeno texto onde resume os slides anteriores.

Neste trabalho o objetivo e explicar, de uma forma concreta eexplıcita, os problemas que podem ocorrer em programacaoconcorrente.

O texto devera: ser elaborado em grupo; enviado por email aoprofessor no final da aula; e devera conter entre 200 a 300palavras.



[email protected]

Arquitetura de Sistemas Operativoshpcosta/so/soMod5BAula4.1.pdf · 2012-04-17 · TGPSI 09/12...

Documents

Transcript of Arquitetura de Sistemas Operativoshpcosta/so/soMod5BAula4.1.pdf · 2012-04-17 · TGPSI 09/12...