Sistemas Operativos Cap. VI Sincronização de Threads

Transcrição

1 Sistemas Operativos Cap. VI Sincronização de Threads Prof. José Rogado Universidade Lusófona 6.1

2 Sincronização de Threads Noções de Concorrência Secções Críticas Soluções Software Hardware de Sincronização Semáforos Problemas Clássicos de Sincronização Monitores Exemplos de Sincronização Transacções Atómicas 6.2

3 Concorrência Vantagens de utilizar execução concorrente Performance Economia Algumas linguagens de programação suportam programação concorrente de forma nativa (Java, C#) Existem vários paradigmas de programação concorrente Não existem modelos gerais Cada modelo requer uma abordagem específica Os suportes da concorrência a nível dos sistemas operativos são geralmente de baixo nível Implementados no hardware 6.3

4 Problemas Acessos simultâneos (concorrentes) a dados partilhados por vários fluxos de execução podem gerar inconsistências Para manter a consistência dos dados são necessários mecanismos para garantir a serialização de fluxos de execução concorrentes Processos cooperando numa mesma aplicação usando memória partilhada Threads dentro de um mesmo processo utilizando as mesmas varáveis globais Identificação das secções críticas de código Acessos concorrentes a dados comuns 6.4

5 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Analogia: Cruzamento de Tráfego 6.5

6 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Secção Crítica: exemplo shared double balance; Code for th 1 Code for th balance = balance + amount; balance = balance - amount; balance+=amount balance-=amount balance 6.6

7 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Secção Critica: problema Execution of th 1 Execution of th 2 load R1, balance load R2, amount Timer interrupt Timer interrupt add R1, R2 store R1, balance load R1, balance load R2, amount sub R1, R2 store R1, balance 6.7

8 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Secção Crítica: definição Secção Crítica (SC): Zona de código que só pode ser utilizada por uma thread de cada vez, em exclusão mútua Existe uma competição entre threads para executar a secção crítica A secção crítica pode ter forma diferente (código) em cada thread Não é facilmente detectavel por análise estatística Sem exclusão mútua, o resultado da execução das threads é indeterminado São necessários mecanismos do SO para resolver os problemas levantados pela concorrência 6.8

9 Estrutura de uma Secção Crítica do { entrada na secção crítica secção crítica Secção Crítica while (TRUE) ; saída da secção crítica resto da thread 6.9

10 Solução do Problema 1. Exclusão Mútua Se a thread T i está a executar uma secção crítica, então nenhuma outra thread pode estar a executar a mesma secção crítica (SC) em simultâneo 2. Progresso Só as threads que competem para uma secção crítica são elegíveis para entrar nessa secção, e a partir do momento em que uma thread requisita o acesso à SC este não pode ser adiado indefinidamente 3. Espera Limitada Depois de uma thread ter requisitado o acesso à SC, só um número limitado de outras threads podem entrar na SC antes deste 6.10

11 Algumas Soluções Possíveis Desactivar as interrupções Só válido em mono-processadores Kernel não preemptivo Perca de performance Utilizar soluções de Software (Peterson) Soluções complexas válidas para poucas threads Situações de bloqueio difíceis de evitar Utilizar soluções de Hardware Instruções específicas do processador Geralmente utilizadas no kernel Fornecidas às aplicações através de APIs de programação de mais alto nível Pthreads Java 6.11

12 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Desactivar as Interrupções shared double balance; Code for th 1 Code for th 2 disableinterrupts(); balance = balance + amount; enableinterrupts(); disableinterrupts(); balance = balance - amount; enableinterrupts(); As interrupções podem ficar desactivadas durante tempos demasiados longos Ao sincronizar th 1 e th 2 está-se a impedir que outras threads possam continuar a sua execução 6.12

13 lock = TRUE Interrupt Interrupt lock = FALSE Interrupt Blocked at while Utilização de uma Variável de Sincronização shared boolean lock = FALSE; shared double balance; Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Code for th 1 Code for th 2 /* Acquire the lock */ /* Acquire the lock */ while(lock) while(lock) ; ; lock = TRUE; lock = TRUE; /* Execute critical sect */ /* Execute critical sect */ balance = balance + amount; balance = balance - amount; /* Release lock */ /* Release lock */ lock = FALSE; lock = FALSE; Espera activa!! p 2 p

14 Falsa Solução!! shared boolean lock = FALSE; shared double balance; Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Code for th 1 Code for th 2 /* Acquire the lock */ /* Acquire the lock */ while(lock) ; while(lock) ; lock = TRUE; lock = TRUE; /* Execute critical sect */ /* Execute critical sect */ balance = balance + amount; balance = balance - amount; /* Release lock */ /* Release lock */ lock = FALSE; lock = FALSE; A thread th 1 testa a variável, e encontra-a com o valor FALSE Decide entrar na secção crítica, sai do while e é interrompido O A thread th 2 testa a variável e encontra-a também a FALSE Decide entrar também na secção crítica Resultado: duas threads na mesma secção crítica 6.14

15 Sincronização Hardware A maioria dos processadores modernos fornecem instruções específicas para implementar secções críticas Atómicas = não interruptíveis Dois tipos mais frequentes Test-and-set Teste de uma variável em memória e modificação do seu valor Swap Troca (swap) os valores de duas variáveis em memória 6.15

16 Instrução Test-and-Set Definição formal: boolean atomic TestAndSet (boolean *target) { boolean rv = *target; *target = TRUE; return rv: 6.16

17 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Detalhe do Test and Set TS(m): [Reg_i = memory[m]; memory[m] = TRUE;] R3 Data Register CC Register Data Register CC Register R3 FALSE =0 m FALSE m TRUE Primary Memory (a) Antes de executar TS Primary Memory (b) Depois de executar TS 6.17

18 Solução utilizando Test-and-Set Variável booleana partilhada lock, inicializada a FALSE. boolean lock = FALSE; // Critical section while (TestAndSet (&lock )) ; // wait // Enter critical section lock = FALSE; // Exit critical section 6.18

19 Solução!! Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. shared boolean lock = FALSE; shared double balance; Code for th 1 Code for th 2 // Acquire the lock // Acquire the lock while(tas(&lock)) while(tas(&lock)) ; ; // Execute critical section // Execute critical section balance = balance + amount; balance = balance - amount; // Release lock // Release lock lock = FALSE; lock = FALSE; A thread th 1 testa a variável, e encontra-a com o valor FALSE Mas a instrução TAS mudou o valor para TRUE no mesmo ciclo A thread th 2 testa a variável e encontra-a com o valor TRUE Espera para entrar na secção crítica Resultado: uma só thread de cada vez na secção crítica 6.19

20 Problema A espera à entrada da secção crítica é feita através de uma espera activa Busy wait Embora não entre na secção crítica, a thread em espera consome CPU e realiza acessos contínuos à memória O Test-and-Set implica acesso à variável de sincronização Esta solução não permite esperas longas Solução: Definição de objectos de sincronização mais complexos que garantam exclusão mútua sem esperas activas Criação de uma Hierarquia de Sincronização 6.20

21 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Semáforos 6.21

22 Definição de Semáforo A noção de Semáforo foi inicialmente proposta por Edsger Dijkstra em Um semáforo contém um valor inteiro que só pode ser modificado através de duas operações indivisíveis (atómicas): Originalmente chamadas P() e V() Proberen (testar) e Verhogen (incrementar) em holandês O nome das operações evoluíram para wait() e signal() Mais de acordo com as suas funcionalidades 6.22

23 Operações sobre um Semáforo Definição de P() - wait() e V() - signal() atomic wait (S) { while (S <= 0) S--; ; // wait atomic signal (S) { S++; atomic wait (S) { waitfor (S > 0); S = S - 1; 6.23

24 Ferramenta de Sincronização Genérica Um semáforo pode ser de contagem (counting) ou binário (mutex) Counting -> sincronização de n recursos distintos O valor inicial do semáforo é um inteiro entre 1 e N. Mutex -> exclusão mútua de secções críticas O valor do semáforo só pode ser 1 ou 0 O Mutex permite criar exclusão mútua em secções críticas Semaphore S; // initialized to 1 wait (S); Critical Section signal (S); 6.24

25 semaphore mutex = 1; thread_create(th_0, 0); thread_create(th_1, 0); Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Exemplos de Utilização th_0() { th_1() { while(true) { while(true { <compute section>; <compute section>; wait(mutex); wait(mutex); <critical section>; <critical section>; signal(mutex); signal(mutex); 6.25

26 Problema do Balanço de Conta semaphore mutex = 1; shared int balance; thread_create(th_0, 0); thread_create(th_1, 0); Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. th_0() { th_1() { /* Enter the CS */ /* Enter the CS */ wait(mutex); wait(mutex); balance += amount; balance -= amount; signal(mutex); signal(mutex);

27 Implementação de Semáforos É preciso garantir que não há mais de uma thread a executar wait() e signal() no mesmo semáforo ao mesmo tempo A implementação reduz-se ao problema da criar uma secção crítica para proteger o código internos das funções wait() e signal() Um semáforo binário pode ser implementado simplesmente com uma instrução Test-and-Set e uma variável binária O valor FALSE indica que o semáforo está livre e TRUE ocupado Mas a espera não pode ser feita desta forma! boolean s = FALSE; // Wait definition wait(s) { while(ts(s)) ; // wait // Signal Definition signal(s) { s = FALSE; 6.27

28 Espera Activa Numa implementação básica de semáforos, a operação wait() implicaria uma espera activa pelo valor positivo do semáforo Busy wait ou Spin lock atomic wait (S) { while (S <= 0) ; // busy wait S = S - 1; A thread testa o valor e caso este seja menor ou igual a zero, volta a testar, continuando a concorrer com os outras threads Está a consumir recursos quando não tem condições para se executar!! 6.28

29 Semáforos sem Espera Activa Uma solução mais correcta é pôr a thread em espera através de invocações explícitas do Scheduler wait(): retira a thread da Ready Queue no caso do semáforo estar ocupado signal(): se houver threads à espera do semáforo, transfere pelo menos um para a Ready Queue (RQ) Assim a espera num semáforo assemelha-se a qualquer outra operação de espera por recursos (p.ex.: I/O) Ao semáforo é associada uma fila de espera de threads e duas rotinas: sleep() retira o processador à thread corrente e coloca-a na em estado waiting fila de espera associada ao semáforo. wakeup() retira pelo menos uma thread da fila de espera do semáforo e volta a inseri-la em estado active na Ready Queue. A nova thread a executar depende dos critérios de scheduling do sistema 6.29

30 Implementação do Semáforo Genérico A implementação de um semáforo com contador é mais complexa e necessita de uma estrutura com três campos: struct semaphore { boolean mutex = FALSE; int value = <initial value>; struct thread *queue = NULL; ; O campo mutex permite criar e proteger a secção crítica correspondente à modificação do valor do semáforo O campo value contém o valor do semáforo (nº de recursos livres) que é negativo no caso de haver threads em espera O campo queue permite colocar a thread numa fila de espera no caso do valor do semáforo ser <= 0 Todos os campos do semáforo são modificados em exclusão mútua através de instruções Test-and-Set sobre o mutex Um semáforo binário é um semáforo genérico com valor inicial =

31 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Implementação com Fila de Espera struct semaphore { struct thread *queue; int value = <initial value>; boolean mutex = FALSE; ; shared struct semaphore s; wait(struct semaphore s){ while(ts(s.mutex)) ; // wait s.value--; if(s.value < 0) { s.mutex = FALSE; sleep(s.queue); else s.mutex = FALSE; signal(struct semaphore s){ while(ts(s.mutex)) ; // wait s.value++; if(s.value <= 0) { while(s.queue == NULL) ; // wait wakeup(s.queue); s.mutex = FALSE; 6.31

32 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Implementação com Fila de Espera struct semaphore { struct thread *queue; int value = <initial value>; boolean mutex = FALSE; ; shared struct semaphore s; O wakeup é feito pela primitiva signal() sempre s.value <= 0 ou seja, sempre que haja threads em espera Neste caso o recurso é transferido da thread que o liberta para uma das threads que está à espera em sleep() wait(struct semaphore s){ while(ts(s.mutex)) ; // wait s.value--; if(s.value < 0) { s.mutex = FALSE; sleep(s.queue); else s.mutex = FALSE; signal(struct semaphore s){ while(ts(s.mutex)) ; // wait s.value++; if(s.value <= 0) { while(s.queue == NULL) ; // wait wakeup(s.queue); s.mutex = FALSE; 6.32

33 Exemplo Th 1 Th 2 Semáforo 6.33

34 Exemplo Th 1 Th 2 Th 2 Semáforo 6.34

35 Exemplo Th 1 Th 2 Semáforo 6.35

36 Deadlock e Starvation Deadlock duas ou mais threads esperam para sempre por um evento que só uma das threads bloqueados pode produzir Se S e Q forem dois semáforos inicializados a 1, a ordem de invocação apresentada conduz a um deadlock T 0 T wait (S); wait (Q); 3 4 wait (Q); signal (Q); signal (S); Deadlock! wait (S); signal (S); signal (Q); Starvation bloqueamento indefinido: uma thread nunca mais é removida da fila de espera em que está colocada, por ser removida numa ordem diferente da que foi colocada 6.36

37 Problemas Clássicos de Sincronização São problemas que retratam de forma simplificada a essência de alguns problemas de sincronização existentes em situações reais Partilha de Dados Problema do Buffer Limitado Problema dos Leitores e Escritores Problema dos Filósofos à Mesa 6.37

38 Sincronização: Partilha de 2 Variáveis Problema: Dois processos P1 e P2 trabalham em cooperação Utilizam duas variáveis partilhadas x e y para trocar valores Os processos têm de se sincronizar para que os valores das variáveis sejam significativos Algoritmo: P1 actualiza x e continua a execução P2 deve ler o valor posto em x por P1 e actualizar y P1 deve esperar que P2 actualize y e ler o seu valor Sincronização Dois semáforos S1 e S2 associados a x e y Os semáforos servem de sincronização entre P1 e P2 Podem também criar um deadlock se forem mal geridos 6.38

39 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Partilha de 2 Variáveis (Cont.) semaphore s1 = 0; // Protects x, initially wait semaphore s2 = 0; // Protects y, initially wait shared int x, y; create_thread(proc_a, 0); create_thread(proc_b, 0); proc_a() { while(true) { <compute section A1>; update(x); /* Signal proc_b */ signal(s1); <compute section A2>; /* Wait for proc_b */ wait(s2); retrieve(y); proc_b() { while(true) { /* Wait for proc_a */ wait(s1); retrieve(x); <compute section B1>; update(y); /* Signal proc_a */ signal(s2); <compute section B2>; 6.39

40 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema do Buffer Limitado Empty Pool Data in Producer Consumer Data out Full Pool Um processo produz dados que outro consome Utilizam uma pool de buffers para passar dados de um para o outro O produtor pode funcionar enquanto houver buffers vazios, e espera quando estiverem todos cheios, até que um esteja vazio O consumidor pode funcionar enquanto houver buffers cheios e espera quando estiverem todos vazios, até que um esteja cheio 6.40

41 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema do Buffer Limitado (2) semaphore mutex = 1; semaphore full = 0; /* A general (counting) semaphore */ semaphore empty = N; /* A general (counting) semaphore */ buf_type buffer[n]; create_thread(producer); create_thread(consumer); producer() { buf_type *data_in, *buffer; while(true) { produce_item(data_in); /* Get an empty buffer */ wait(empty); wait(mutex); buffer = get(emptypool); signal(mutex); copy_buffer(data_in, buffer); wait(mutex); release(buffer, fullpool); signal(mutex); /* Signal a full buffer */ signal(full); consumer() { buf_type *data_out, *buffer; while(true) { /* Get a full buffer */ wait(full); wait(mutex); buffer = get(fullpool); signal(mutex); copy_buffer(buffer, data_out); wait(mutex); release(buffer, emptypool); signal(mutex); /* Signal an empty buffer */ signal(empty); consume_item(data_out); 6.41

42 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema do Buffer Limitado (2) semaphore mutex_empty = 1, mutex_full = 1; semaphore full = 0; /* A general (counting) semaphore */ semaphore empty = N; /* A general (counting) semaphore */ buf_type buffer[n]; create_thread(producer); create_thread(consumer); producer() { buf_type *data_in, *buffer; while(true) { produce_item(data_in); /* Get an empty buffer */ wait(empty); wait(mutex_empty); buffer = get(emptypool); signal(mutex_empty); copy_buffer(data_in, buffer); wait(mutex_full); release(buffer, fullpool); signal(mutex_full); /* Signal a full buffer */ signal(full); Um mutex por cada pool: melhor consumer() { buf_type *data_out, *buffer; while(true) { /* Get a full buffer */ wait(full); wait(mutex_full); buffer = get(fullpool); signal(mutex_full); copy_buffer(buffer, data_out); wait(mutex_empty); release(buffer, emptypool); signal(mutex_empty); /* Signal an empty buffer */ signal(empty); consume_item(data_out); 6.42

43 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema dos Leitores e Escritores Escritores Leitores 6.43

44 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema dos Leitores e Escritores (2) Reader Reader Reader Reader Reader Reader Reader Reader Writer Writer Writer Writer Writer Writer Writer Shared Resource Um conjunto de processos realizam acessos a um recurso comum, uns para escrever, outros para ler o seu conteúdo Ficheiro, BD, É necessário garantir a coerência dos valores 6.44

45 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema dos Leitores e Escritores (3) Writer Writer Writer Writer Writer Writer Writer Reader Reader Reader Reader Reader Reader Reader Reader Shared Resource N leitores podem-se executar simultaneamente 6.45

46 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema dos Leitores e Escritores (4) Reader Reader Reader Reader Reader Reader Reader Reader Writer Writer Writer Writer Writer Writer Shared Resource Writer Só um escritor se pode executar de cada vez Quando um escritor está activo, os leitores esperam Quando há leitores activos, o escritor espera 6.46

47 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. resourcetype *resource; int readcount = 0; semaphore mutex = 1; semaphore writeblock = 1; create_thread(reader, 0); create_thread(writer, 0); reader() { while(true) { <other computing>; wait(mutex); readcount++; if(readcount == 1) wait(writeblock); signal(mutex); read(resource); /* Critical section */ wait(mutex); readcount--; if(readcount == 0) signal(writeblock); signal(mutex); Primeira Solução O primeiro leitor bloqueia os escritores O primeiro escritor bloqueia os leitores O último leitor desbloqueia os escritores Qualquer escritor espera por todos os leitores Os leitores podem causar starvation dos escritores porque as actualizações não passam writer() { while(true) { <other computing>; /* Critical section */ wait(writeblock); write(resource); signal(writeblock); 6.47

48 Segunda Solução O algoritmo é modificado para privilegiar os escritores Os leitores continuam a poder ler sem exclusão mútua Se aparece um escritor e está um leitor activo, o escritor espera Se um leitor aparece com um escritor em espera, o leitor espera que o escritor saia Se um segundo escritor aparece, tem prioridade sobre os leitores que podem esperar indefinidamente Esta solução é complexa e necessita uma implementação cautelosa para evitar deadlocks e starvation Veremos uma solução mais robusta baseada em monitores 6.48

49 Prioridade aos Escritores Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. int readcount = 0, writecount = 0; semaphore mutex1 = 1, mutex2 = 1; semaphore readblock = 1, writeblock = 1; create_thread(reader, 0); create_thread(writer, 0); reader() { while(true) { <other computing>; wait(readblock); wait(mutex1); readcount++; if(readcount == 1) wait(writeblock); signal(mutex1); signal(readblock); read(resource); wait(mutex1); readcount--; if(readcount == 0) signal(writeblock); signal(mutex1); writer() { while(true) { <other computing>; wait(mutex2); writecount++; if(writecount == 1) wait(readblock); signal(mutex2); wait(writeblock); write(resource); signal(writeblock); wait(mutex2) writecount--; if(writecount == 0) signal(readblock); signal(mutex2); 6.49

50 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Problema dos Filósofos à Mesa Cinco filósofos estão sentados a uma mesa a comer massa: Cada um tem um talher de cada lado, que partilha com o seu vizinho do lado Cada filósofo só pode comer quando ficam livres simultaneamente os dois talheres de cada lado do seu prato Dois filósofos sentados ao lado um do outro não podem comer ao mesmo tempo. 6.50

51 Problema dos Filósofos à Mesa Para resolver o problema vamos atribuir um índice a cada filósofo, com i variando de 0 a 4 A cada garfo associa-se um semáforo designado por garfo(i) O filósofo i pode comer quando estão livres simultaneamente os semáforos garfo (i) e garfo ((i+1) % 5), ou seja: garfo(0) e garfo(1) garfo(1) e garfo(2) garfo(2) e garfo(3) garfo(3) e garfo(4) garfo(4) e garfo(0) 6.51

52 Primeira Solução Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. semaphore garfo[5] = (1,1,1,1,1); fork (filosofo, 1, 0); fork (filosofo, 1, 1); fork (filosofo, 1, 2); fork (filosofo, 1, 3); fork (filosofo, 1, 4); filosofo (int i) { while(true) { // Think // Eat wait(garfo[i]); wait(garfo[(i+1) % 5]); eat(); signal(garfo[(i+1) % 5]); signal(garfo[i]); garfo(i) filosofo(i) garfo(i+1) 6.52

53 Primeira Solução Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. semaphore garfo[5] = (1,1,1,1,1); fork (filosofo, 1, 0); fork (filosofo, 1, 1); fork (filosofo, 1, 2); fork (filosofo, 1, 3); fork (filosofo, 1, 4); filosofo (int i) { while(true) { // Think // Eat wait(garfo[i]); wait(garfo[(i+1) % 5]); eat(); signal(garfo[(i+1) % 5]); signal(garfo[i]); Se todos os filósofos acederem simultaneamente aos talheres do mesmo lado (esquerdo ou direito), cria-se uma solução de Deadlock 6.53

54 Segunda Solução Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. semaphore garfo[5] = (1,1,1,1,1); fork (filosofo, 1, 0); fork (filosofo, 1, 1); fork (filosofo, 1, 2); fork (filosofo, 1, 3); fork (filosofo, 1, 4); filosofo (int i) { while(true) { // Think // Eat j = i % 2; wait(garfo[(i+j) % 5]); wait(garfo[(i+1-j) % 5]); eat(); signal(garfo[(i+1-j) % 5]); signal(garfo[[(i+j) % 5]); Na primeira escolha, os filósofos de índice par acedem ao garfo esquerdo, e os de índice ímpar, o garfo direito Na segunda escolha inverte-se a ordem 6.54

55 Segunda Solução Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. semaphore garfo[5] = (1,1,1,1,1); fork (filosofo, 1, 0); fork (filosofo, 1, 1); fork (filosofo, 1, 2); fork (filosofo, 1, 3); fork (filosofo, 1, 4); garfo(3) filosofo(2) garfo(2) filosofo (int i) { filosofo(3) while(true) { // Think // Eat j = i % 2; garfo(4) wait(garfo[(i+j) % 5]); wait(garfo[(i+1-j) % 5]); eat(); signal(garfo[(i+1-j) % 5]); signal(garfo[[(i+j) % 5]); 6.55 filosofo(4) filosofo(1) garfo(0) Na primeira escolha, os filósofos de índice par acedem ao garfo esquerdo, e os de índice ímpar, o garfo direito Na segunda escolha inverte-se a ordem garfo(1) filosofo(0)

56 Problemas de Utilização dos Semáforos As operações sobre os semáforos têm de ser usadas correctamente Se há troca de ordem, pode haver vários processos na secção crítica wait (mutex) // Secção Crítica wait (mutex) Se houver troca de funções, gera-se um deadlock signal (mutex) // Secção Crítica wait (mutex) Se houver omissão de uma das funções, um dos dois casos anteriores pode acontecer É relativamente frequente em programas complexos acontecerem situações deste tipo que não são fáceis de detectar Para evitar estas situações, algumas linguagens utilizam ferramentas de sincronização mais fáceis de utilizar 6.56

57 Monitores Uma extensão do conceito de semáforo de mais alto nível que fornece uma interface eficaz e fácil de utilizar para sincronização de threads ou processos Conceito de programação Orientada aos Objectos Embebida nas linguagens Concurrent Pascal, Java e C# Gerida pelo compilador O monitor encapsula (esconde) a sua implementação Só são acessíveis métodos e dados públicos Os métodos e dados privados são só utilizados pelo monitor O monitor garante exclusão mútua dos processos que o executam: monitor mon { private: semaphore mutex = 1; // Implícito... public: method_i( ) { wait(mutex); // Implícito <code for proc_i>; signal(mutex); // Implícito ; ; 6.57

58 Exemplo: Shared Balance O problema da partilha da variável balance é resolvido através da declaração de um monitor contendo: Uma variável privada balance Dois métodos públicos que são executados no interior do monitor com exclusão mútua implícita monitor sharedbalance { private: double balance; public: credit(double amount){ balance += amount; debit(double amount){ balance -= amount;

59 Balanço de Conta c/ Monitores monitor sharedbalance; thread_create(deposit); thread_create(withdraw); Os métodos deposit() e withdraw() são executados no interior do monitor, que garante a exclusão mútua da secção crítica através de uma variável de sincronização implícita deposit() {... sharedbalance.credit(amount);... withdraw() {... sharedbalance.debit(amount);

60 Representação de um Monitor 6.60

61 Variáveis de Condição Os monitores fornecem também mecanismos que permitem às threads esperar que se verifiquem condições específicas Designam-se por Variáveis de Condição Geralmente, são definidas duas operações sobre uma VC x condition_wait (x) permite a uma thread que invoca esta operação ser suspensa até a condição se verificar condition_signal (x) permite a uma thread sinalizar o facto de que a condição se verificou, e activar uma das threads que estiverem em espera Não é geralmente garantido que a thread activada seja a que mais tempo tenha esperado A forma como as threads são reactivadas por condition_signal() depende da implementação do monitor e do algoritmo de scheduling 6.61

62 Um Monitor com Variáveis de Condição 6.62

63 Estrutura de um Monitor Variáveis de Sincronização do Monitor Um mutex para exclusão mútua no monitor, inicializado a 1 Um mutex de sinalização no monitor, inicializado a 0 Um contador de processos em espera semaphore mutex = 1; // monitor mutex, initially = 1 semaphore other = 0; // signaling mutex, initially = 0 int others_waiting = 0; // number waiting for signaling Variáveis de Condição do Monitor: para cada condição é introduzida uma variável com a seguinte estrutura Um semáforo de sinalização inicializado a 0 Um contador de processos em espera na variável struct condvar x { semaphore sem; // initially = 0 int count = 0; // waiting on x ; 6.63

64 Source: Operating Systems, Gary Nutt Copyright 2004 Pearson Education, Inc. Readers & Writers com Monitores monitor readerwriter { int numberofreaders = 0; boolean busy = FALSE; condition oktoread, oktowrite; public: startread() { if(busy (oktowrite.queue()) oktoread.wait(); numberofreaders++; oktoread.signal(); finishread() { numberofreaders--; if(numberofreaders == 0) oktowrite.signal(); startwrite() { if((numberofreaders!= 0) busy) oktowrite.wait(); busy = TRUE; finishwrite() { busy = FALSE; if(oktoread.queue()) oktoread.signal() else oktowrite.signal() 6.66

65 Hierarquia de Sincronização Os vários objectos que descrevemos formam uma hierarquia de sincronização Baseada em suporte hardware Cada nível utiliza as funcionalidades do anterior e estende-a com capacidades adicionais Permite garantir a vários níveis de implementação a correcção de aplicações concorrentes Monitor Semáforo Mutex Spin-lock Test -and-set 6.67

66 Exemplos de Sincronização Windows POSIX Linux 6.68

67 Sincronização em Windows São fornecidos dois mecanismos para exclusão mútua Mutexes Critical Sections Os mutexes são geridos pelo sistema operativo através das primitivas HANDLE CreateMutex(attributes, Owner, Name) WaitforSingleObject(HANDLE, timeout) ReleaseMutex(HANDLE) As CriticalSections secções críticas permitem criar zonas de código protegido sem ter explicitamente de manipular mutexes InitializeCriticalSection( ) EnterCriticalSection( ) LeaveCriticalSection( ) 6.69

68 Sincronização POSIX A sincronização POSIX permite gerir exclusão mútua em ambientes multiprogramados utilizando a API das pthreads A API é independente do Sistema Operativo e fornece: mutex locks condition variables Extensões não dependentes do SO fornecem também: read-write locks spin locks 6.70

69 API POSIX para Sincronização Gestão de Mutexes pthread_mutex_init (mutex,attr) pthread_mutex_lock (mutex) pthread_mutex_trylock (mutex) pthread_mutex_unlock (mutex) Gestão de Condition Variables pthread_cond_init (condition,attr) pthread_cond_wait (condition,mutex) pthread_cond_signal (condition) pthread_cond_broadcast (condition) Utilização pthread_cond_wait deve ser invocada com um mutex locked, a função liberta-o implicitamente pthread_cond_signal deve ser invocada com um mutex locked que é necessário depois libertar para que uma thread que está em espera possa ser reactivada 6.71

70 Sincronização no Kernel Linux Utiliza spinlocks baseados em TAS em ambiente multiprocessador O kernel é preemptível desde a versão 2.6, mas quando um processo kernel obtém um lock, esta possibilidade é suspensa através da manutenção de um contador do número de preempções em curso (preempt_count) por processo kernel Quando as secções críticas de código são extensas, utilizam-se semáforos System call futex() Fast Userspace mutexes permite a implementação de mutex e semáforos em modo utilizador com recurso mínimo a funções do kernel

71 Exemplo 1: API POSIX Uma thread produtora recebe dados de um canal de I/O Para os armazenar, retira um buffer da lista dos buffers vazios, preenche-o com os dados recebidos e insere-o na lista dos buffers cheios Uma outra thread consumidora retira um buffer da lista dos buffers cheios, envia os dados para tratamento e volta a colocar esse buffer na lista dos buffers vazios A thread produtora espera que haja buffers vazios A thread consumidora espera que haja buffers cheios Inicialmente os buffers estão todos vazios Ver ficheiro

72 Exemplo 2: API POSIX Uma thread insere processos em N filas de espera ordenando-os por prioridade Uma outra thread retira-os por ordem de prioridade decrescente Duas actividades concorrentes que criam uma secção crítica ao poderem modificar simultaneamente as filas de espera Solução: utilização de um mutex para proteger a secção crítica Por outro lado, a remoção de processos deve ser comandada por um evento (sinal) que activa a thread Solução: utilização de uma variável de condição na qual a thread de selecção vai esperar Ver ficheiro

73 Fim do Capítulo