Arquitetura de Sistemas Operativos

Transcrição

1 Arquitetura de Sistemas Operativos Sistemas Operativos 2011/2012

2 1

3 Necessidade das As tarefas que se executam em paralelo não são normalmente independentes, tendo de se sincronizar para poderem executar um algoritmo global comum. Existem diversos motivos que justificam a necessidade de sincronizar explicitamente essas tarefas. Para simplificar a sua análise agrupamo-los em duas categorias: competição de várias tarefas por um determinado recurso e cooperação entre tarefas.

4 Considere-se o exemplo seguinte: uma conta bancária a que várias tarefas pretendem aceder ou atualizar. O código seguinte mostra uma função em linguagem C, que poderia fazer parte de um programa que permite efetuar várias operações de índole bancária.

5 Função que permite levantar dinheiro de uma conta bancária 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; }

6 Esta função suporta uma funcionalidade similar à que encontramos disponibilizada nas máquinas multibanco: levantar dinheiro. Na realidade, os sistemas bancários não funcionam desta forma, mas poderíamos conceptualmente considerar que existia um servidor no banco que executava os pedidos vindos de uma máquina multibanco e que, a cada pedido, dedicava uma tarefa de modo a suportar paralelismo no atendimento. Os servidores bancários seriam assim implementados de forma a servir os pedidos efetuados pelas máquinas multibanco em paralelo, portanto, o código em causa seria executado por várias tarefas concorrentemente.

7 A operação descrita na função anterior permite efetuar um débito, no valor indicado pelo segundo argumento da função, numa conta identificada pelo primeiro argumento (referência para uma zona de memória do tipo conta t). O objeto referenciado pelo argumento conta tem um campo denominado saldo cujo valor corresponde ao saldo da conta em causa. Considerando a função numa óptica de programação sequencial, esta não tem qualquer erro.

8 Obviamente, é crucial que todas as operações bancárias sejam efetuadas de modo a que seja assegurada a sua consistência em termos financeiros. Como o programa é concorrente, o que se pretende é que, apesar de existirem várias tarefas, o funcionamento do sistema seja equivalente ao que se obteria caso as tarefas se executassem sequencialmente. Em particular, não deverá ocorrer, em nenhuma circunstância, uma situação em que seja permitido efetuar débitos não contabilizados ou para os quais não haja saldo disponível. Vamos ver um exemplo onde tal sucede.

9 Suponhamos que existe uma conta solidária com dois membros que a podem movimentar livremente e que ambos tentam ao mesmo tempo, em máquinas multibanco distintas, levantar uma determinada quantia de dinheiro. Portanto, a referida função é invocada concorrentemente por duas tarefas (dentro do processo servidor bancário) em que cada uma serve um pedido de débito sobre a mesma conta. Numa observação menos atenta podemos ser levados a concluir que não há nenhum problema resultante desta situação, no entanto, uma observação mais cuidada leva-nos à conclusão oposta.

10 Com efeito, considerando que neste exemplo temos duas tarefas que executam o código em causa, e que o código if (... ).. else... corresponde de facto a várias instruções que são executadas de forma sequencial pelo processador, pode suceder a situação ilustrada na figura seguinte que apresenta a evolução temporal das instruções executadas pelas duas tarefas.

11

12 A tarefa T2 executou o código da função levantar dinheiro de forma intercalada com a tarefa T1. Como se pode observar, esta comutação de tarefas ocorre de tal forma que, logo após o teste efetuado por T1, esta perde o processador para T2. A instrução que T1 executa como resultado do teste só é de facto executada depois de T2 ter executado, na totalidade, a função levantar dinheiro, ou seja, como T1 tinha efetuado o teste, não o vai repetir quando o despacho a selecionar novamente, uma vez que o program counter já referencia a instrução seguinte.

13 Nestas circunstâncias, assumindo que o saldo inicial tinha o valor 100 e que as duas operações de levantamento pretendiam retirar da conta respectivamente 30 por T1 e 90 por T2, o que sucederia é que no teste inicial de T1, 100>=30 era verdadeiro, em seguida na tarefa T2 o teste também era válido porque 100>=90 uma vez que o valor do saldo não tinha sido subtraído da quantia a levantar em T1. No final o valor do saldo da conta em causa seria: = -20 Portanto, teria sido permitido um levantamento sem que houvesse cobertura para tal.

14 À primeira vista, esta situação de intercalação das tarefas T1 e T2 pode parecer forçada: T1 perde o processador imediatamente após ter efetuado o teste if (conta>saldo>=valor) e antes de executar a instrução seguinte. No entanto, isso não é verdade por duas razões: Primeiro, na aplicação em causa teremos inúmeras execuções desta função pelo que a probabilidade de vir a acontecer a referida intercalação é relevante. Segundo, cada instrução na linguagem C resulta, de facto, em várias instruções máquina executadas pelo processador.

15 A razão que está na base deste funcionamento erróneo é o facto de estarmos a considerar um sistema operativo multiprogramado no qual é perfeitamente possível que a tarefa T1 perca o processador (e.g., o seu time-slice esgotou-se), a meio da função em causa e, que a tarefa T2 seja, em seguida, escalonada pelo sistema operativo. O erro existe porque o bloco de código deveria ser executado na sua totalidade pela tarefa T1 e só depois pela tarefa T2 (ou vice-versa) uma vez que ambas acedem à mesma conta.

16 Ou seja, as instruções deveriam ser executadas em exclusão mútua ou, dito de outra maneira, de forma indivisível ou atómica. O bloco de código em causa é então designado como uma secção crítica.

17 De uma forma geral, o problema apresentado ocorre quando uma tarefa testa uma variável e, em função do seu valor, decide ou não modificá-la. Pode suceder que outra tarefa, que entretanto se executa concorrentemente, decida também testá-la. A execução do programa torna-se incoerente dado que sucedeu algo não previsto no modelo de programação sequencial pois a variável mudou de valor, depois do teste, através de uma ação exterior.

18 Para que fique claro este aspeto fundamental da sincronização, é apresentado em seguida um segundo exemplo que nos vai permitir ilustrar diversos conceitos de sincronização. Consideremos um alocador de memória (programa para reservar blocos de memória) muito simples num sistema concorrente. As tarefas que pretendam reservar memória invocam as funções deste alocador.

19 O algoritmo de atribuição de blocos de memória é suportado por uma estrutura de dados implementada por uma pilha. Os elementos da pilha indicam o endereço inicial do bloco de memória. Para simplificar o algoritmo, vamos supor: que todos os blocos são idênticos, com um tamanho definido inicialmente; as tarefas apenas podem pedir blocos completos, não fazendo o sistema qualquer subdivisão dos blocos. O código na linguagem C correspondente a este alocador de memória é apresentado de seguida.

20 Funções de um alocador de memória 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; }

21 Para pedir um bloco de memória, uma tarefa executa a função PedeMem que tem como parâmetro de saída o apontador para o bloco de memória. Para devolver a zona de memória ao alocador, chama a função DevolveMem.

22 Como foi referido anteriormente, a estrutura de dados é uma pilha implementada da forma mais simples: através de um vector de apontadores indexado por uma variável que referencia o apontador para o próximo bloco de memória a atribuir. Pilha e topo são variáveis globais do programa alocador de memória, que são convenientemente inicializadas no início da execução.

23 Aparentemente, a estrutura anterior funciona de acordo com o objetivo pretendido. Contudo, se analisarmos com maior detalhe o programa, detetamos novamente problemas resultantes da concorrência entre as diversas tarefas. Com efeito, suponhamos que uma tarefa T1 inicia a devolução de memória mas, devido a uma interrupção, é-lhe retirado o processador (e.g., imediatamente após a instrução topo++).

24 Consideremos que a tarefa T2 que se executa em seguida pretende pedir memória. Neste caso somos conduzidos a uma situação que originará um erro no funcionamento do sistema: o endereço do bloco de memória que a tarefa T2 obtém é inválido; a tarefa T1 apenas tinha incrementado a variável topo e não tinha ainda actualizado o apontador que ela passou a referenciar; o apontador que estará no bloco pode ser inválido ou corresponder a um bloco de memória que foi atribuído a outra tarefa anteriormente.

25 Outras situações de potencial erro aparecem na função PedeMem se for interrompida antes de decrementar a variável topo. Estes exemplos podem parecer forçados, pois pressupõem uma certa sequência de acontecimentos.

26 No entanto, é preciso considerar que as operações em causa (e.g., levantar dinheiro ou pedir e devolver memória): podem ser executadas milhões de vezes no decorrer da vida de um sistema e que, mesmo para um encadeamento da execução das tarefas com pequena probabilidade, existe a possibilidade de ela vir a verificar-se, reforçado pelo facto de as interrupções que provocam a comutação das tarefas serem servidas depois de qualquer instrução máquina e não depois das instruções de C.

27 É ainda de considerar que um erro deste tipo pode ter uma caraterística aparentemente aleatória (aparece de tempos a tempos), o que o torna extremamente difícil de detetar. Esta aleatoriedade está na base da denominação destes erros como Heisenbugs 1, por analogia com o princípio da incerteza de Heisenberg. 1

28 É importante identificar claramente a origem dos erros que se verificam nos exemplos anteriores. No que diz respeito ao exemplo do alocador de memória, a tarefa T2 utiliza um apontador de memória que não é válido, porque o valor da variável topo não está coerente com o estado da tabela pilha. As duas variáveis representam o estado global do alocador de memória e a sua modificação não foi feita de forma atómica, conduzindo a que o estado da pilha seja incoerente. Estas variáveis têm de ser atualizadas em conjunto, não se podendo permitir atualizações parciais.

29 Em conclusão, em programação concorrente sempre que se testa e se modifica estruturas de dados partilhadas (uma simples variável, tabelas ou estruturas dinâmicas) é necessário garantir que as operações são executadas dentro de uma secção crítica. Esta caraterística tem a ver com o mecanismo de base de suporte à multiprogramação e, portanto, é intrínseca a todos os sistemas operativos.

30 Em programação concorrente sempre que se testam ou se modificam estruturas de dados partilhados é necessário efetuá-lo dentro de uma secção crítica.

31 Avaliação - Trabalho Teórico-Prático 9 Escreve um pequeno texto onde resume os slides anteriores. Neste trabalho o objetivo é explicar, de uma forma concreta e expĺıcita, os problemas que podem ocorrer em programação concorrente. O texto deverá: ser elaborado em grupo; enviado por ao professor no final da aula; e deverá conter entre 200 a 300 palavras.