• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Canais Síncronos
 

Canais Síncronos

on

  • 1,269 views

 

Statistics

Views

Total Views
1,269
Views on SlideShare
1,269
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Canais Síncronos Canais Síncronos Presentation Transcript

    • II. Memória Distibuída Passagem de Mensagens Síncrona Fco. Heron de Carvalho Jr., Dr. [email_address]
    • Introdução
      • Dificuldades com Passagem de Mensagens Assíncrona
        • Transmissor precisa saber se receptor recebeu a mensagem:
          • Uso de reconhecimento ;
        • Entrega de mensagens não é garantida;
          • Como saber o que ocorreu caso o reconhecimento não chegue ??
        • Buffers não podem ser infinitos
          • Muitas mensagens  CRASH! ou bloqueio no send;
          • Violação da semântica do send ;
    • Introdução
      • Passagem de Mensagens Síncrona
        • Não há buffers ;
        • Processo transmissor espera até que o receptor receba a mensagem;
        • Comando de atribuição distribuída;
        • Vantagens:
          • Simplifica a solução de alguns problemas;
          • Evita alocação dinâmica de buffers ;
        • Desvantagens:
          • Dificulta programação de alguns problemas;
        • CSP e OCCAM (Hoare)
    • Notação
      • Processo A deseja comunicar um valor a um processo B :
        • A:: … B! e … {comando de sa ída}
        • B:: … A? x … {comando de entrada}
      • A fica bloqueado até que B receba o valor e e atribua a sua variável x ;
      • Os tipos de e e x devem coincidir;
    • Notação
      • Forma geral:
        • destino ! porta (e 1 ,…,e n )
        • fonte ? porta (x 1 ,…,x n )
      • Portas são usadas para identificar os tipos de mensagens;
        • Alternativa ao simples casamento de tipos que pode causar confusão;
    • Notação
      • Casando comandos de comunicação:
        • Um comando de saída e um comando de entrada casam se todos as 4 condições seguintes são aceitas:
          • O comando de saída aparece no processo nomeado pelo comando de entrada ;
          • O comando de entrada aparece no processo nomeado pelo comando de saída ;
          • Os identificadores das portas são os mesmos e, caso presentes, os valores subscritos também;
          • Todos os x i := e i são atribuições válidas;
    • Notação
      • Exemplo 1:
      • Copy :: var c:char do true  West ? c ; East ! c od
      • Exemplo 2:
      • GCD :: var x,y: int do true  Client ? args ( x , y ) do x  y  x := x - y [] x  y  y := y - x od Client ! r esult ( x ) od
    • Notação
      • Uso de GCD pelo cliente:
      • … GCD ! a rgs ( v1 , v2 ); ...; GCD ? result (r) …
    • Notação
      • Comunica ção guardada ;
        • Processos querem se comunicar com mais de um processo mas em uma ordem arbritária;
        • Exemplos:
          • Copy com buffer : se há mais de 1 e menos de 10 caracteres no buffer, pode-se ler de West ou escrever em East ;
          • GCD pode ter múltiplos clientes;
    • Notação
      • Comunica ção guardada ;
        • Comando de comunicação guardado
          • B ; C  S
            • B é uma expressão booleana (opcional);
            • C é um comando de comunicação (opcioinal);
            • S é uma lista de comandos;
        • B e C compõem a guarda;
        • A guarda sucede-se se B é verdadeiro e C não causa bloqueio ;
    • Notação
      • Comunica ção guardada ;
        • Uso com if
          • Uma das guardas ativas é escolhida não-deterministicamente ;
        • Uso com do
          • Repetidamente, uma das guardas ativas é escolhida não-deterministicamente, at é quando nenhuma estiver ativa;
    • Notação
      • Uso de comunicação guardada em Copy :
      • Copy :: var c:char do West ? C  East ! c od
      • Copy :: var buffer [1:10]:char var front :=1, rear :=1, count :=0 do count < 10; West ? buffer [ rear ]  count ++; rear := ( rear mod 10) + 1 [] count > 0; East ! buffer [ front ]  count --; front := ( front mod 10) + 1 od
    • Notação
      • Uso de comunicação guardada em GCD :
      • GCD :: var x,y: int do (i:1..n) Client [i] ? a rgs [i] ( x , y )  do x  y  x := x - y [] x  y  y := y - x od Client [ i ] ! r esult [i] ( x ) od
    • Notação
      • A::var x,y:int; if B!x  B?y [] B?y  B!x fi
      • B::var x,y:int; if A!x  A?y [] A?y  A!x fi
    • Semântica Formal
      • Passos para construir a prova de um programa por passagem de mensagens sícrona:
        • Prova individual de cada processo;
        • Mostrar não-interferência;
        • Mostrar que as suposições de comunicação são satisfeitas;
          • Regra de satisfação;
    • Semântica Formal
      • Considere os comandos de comunicação:
        • out: Destino ! porta (e 1 ,...,e n )
        • In : Fonte ? porta (x 1 ,...,x n )
      • Se dois comandos de comunica ção casam , o efeito é a atribuição das expressões para as variáveis;
      • Caso contrário, deadlock !
        • Qualquer coisa pode ser concluída como pós-condição desses comandos de atribuição;
    • Semântica Formal
      • Axioma da Saída:
        • {P} out: Destino ! porta (e 1 ,...,e n ) {U}
      • Axioma da Entrada
        • {Q} in: Fonte ? porta (x 1 ,...,x n ) {V}
      • Prova de satisfação
        • (P  Q)  wp (x 1 ,...x n := e 1 ,...e m , U  V)
    • Semântica Formal
      • Regra da Satisfação comunicação síncrona
        • Seja in um comando de entrada com pré-condição P e pós-condição U.
        • Seja out um comando de saída com pré-condição Q e pós-condição V.
        • Para todos os tais pares de comandos de comunicação casados, temos:
    • Semântica Formal
      • Novas regras de inferência para if e do
        • Comandos de atribuição podem aparecer nas guardas;
        • Transformando comandos de comunicação guardados em comandos guardados simples correspondentes;
          • B; C  S tem o mesmo efeito de B  C; S para efeito de prova;
          • O segundo é mais sujeito a deadlocks ;
    • Semântica Formal
      • Regra da alternativa
        • CIF : if B 1 ; C 1  S 1 [] ... [] B n ; C n  S n fi
    • Semântica Formal
      • Regra da iteração
        • CDO : do B 1 ; C 1  S 1 [] ... [] B n ; C n  S n od
      • Prova de não-interferência
        • Uso de variáveis auxiliares exige prova de não-interferência ;
        • Variáveis auxiliares em em comunicação síncrona
          • U em geral para construir a prova de um programa, não afetando seu comportamento;
      Semântica Formal
    • Semântica Formal
      • Restrição da variável auxiliar
        • Variáveis auxiliares somente aparecem:
          • Como destinos em comandos de atribuição ou em expressões à direita em comandos de atribuição contanto que o destino correspondente da atribuição seja uma variável auxiliar;
          • Como variáveis em comandos de entrada ou em expressões em comandos de saída , contanto que a correspondente variável em qualquer comando de entrada casado seja uma variável auxiliar e o conjunto de comandos de atribuição casados não são afetados pela presença de variáveis auxiliares;
    • Semântica Formal
      • Prova de não-interferência
        • Mostrar que cada assertiva crítica C na prova de um processo é invariante com respeito a execução de qualquer ação em outro processo;
        • Comando S e assertiva C são paralelos quando pertencem a processos distintos ;
    • Semântica Formal
      • Prova de não-interferência
        • Para provar que uma ação de atribuição a não invalida uma assertiva crítica C paralela a a , é suficiente mostrar que NI( a , C ) é um teorema:
          • NI( a , C): {pre( a )  C} a {C}
        • Sejam in e out comandosde comunicação, a prova de NI( in ,C) e NI( out ,C) é trivialmente verdade , pelos axiomas de entrada;
    • Semântica Formal
      • Prova de não-interferência
    • Semântica Formal
      • Liberdade de interferência para comunicação síncrona. Teoremas {Pi} Si {Qi}, 1  i  n são livres de interferencia se ambos os seguintes são verdade:
        • Para todas as atribuições e a na prova de S i , 1  i  n e para todas as assertivas críticas paralelas a a : NI ( a, C ).
        • Para todas as ações de entrada in na prova de S i , 1  i  n, para todas as ações de saída casadas out na prova de S j , 1  j  n, i  j, e para todas as assertivas críticas paralelas a in e out : NIasynch ( in , out, C ).
    • Semântica Formal
      • Exemplo ( seção crítica ):
      • C[1:n]:: do true  Sem !P() critical section Sem !V() non-critical section od Sem :: do ( i :1..n) C[ i ] ? P()  C[ i ] ? V() od
    • Semântica Formal
      • Exemplo ( seção crítica ):
        • Variáveis auxililares;
          • Lembra se processo C[i] está na seção crítica;
          • in[1:n]: bool;
        • Invariante:
          • MUTEX: (  i: 1  i  n: 0  in[i]  1)  (in[1] + ... In[n])  1
    • Semântica Formal
      • var in[1..n]: int := ([n] 0) { MUTEX:(  i: 1  i  n: 0  in[i]  1)  (in[1] + ... In[n])  1} C[1:n]:: do true  {MUTEX  in[i]=0} Sem !P( 1 ) {MUTEX  in[i]=1} critical section Sem !V( 0 ) {MUTEX  in[i]=0} non-critical section od Sem :: {MUTEX  (in[1]+...+in[n]=1)=1} do ( i :1..n) C[ i ] ? P( in[i] )  {MUTEX  (in[1]+...+in[n]=1)=1} C[ i ] ? V( in[i] ) {MUTEX  (in[1]+...+in[n]=1)=0} od
    • Semântica Formal
      • Exemplo ( seção crítica ):
        • Isoladamente, as provas de cada processo são verdadeiras;
          • As únicas ações de atribuições são os comandos de atribuição;
        • Prova de satisfação:
          • Existem dois pares de comandos de atribuição casados;
            • Porta P;
            • Porta V;
    • Semântica Formal
      • Exemplo ( seção crítica ):
        • Prova de Satisfação:
        • Para o par que se comunica pela porta P:
          • (MUTEX  in [ i ]=0  ( in [1] + ... + in [ n ]) = 0)  (MUTEX  in[i] = 1  ( in [1] + ... + in [ n ]) = 1) 1 in[i]
        • Para o par que se comunica pela porta V:
          • (MUTEX  in [ i ]=1  ( in [1] + ... + in [ n ]) = 1)  (MUTEX  in[i] = 0  ( in [1] + ... + in [ n ]) = 0) 0 in[i]
    • Semântica Formal
      • Exemplo ( seção crítica ):
        • Prova de não-interferencia:
          • Uma vez que as unicas ações de atribuições são os comandos de comunicação, a primeira parte da prova é verdadeira trivialmente ;
          • A única fonte eventual de não-interferência : ações de comunicação em dois processos em relação a uma assertiva em um terceiro ;
    • Semântica Formal
      • Exemplo ( seção crítica ):
        • Prova de não-interferencia:
          • Exemplo : Considere o primeiro comando de saída ( out ) em C[i], o primeiro comando de entrada de Sem ( in ) e a primeira assertiva crítica de C[j] (C)
            • pre(in) = {MUTEX  in[i]=0}
            • pre(out) = {MUTEX  (in[1]+...+in[n]=1)=0}
            • C = {MUTEX  in[j]=0}
    • Semântica Formal
      • Exemplo ( seção crítica ):
        • Prova de não-interferencia:
          • NIsynch(in,out,C) = { MUTEX  ( in [1]+...+ in [n]=1)=0  in [ i ]=0  in [ j ]=0}  MUTEX  in [ j ]=0) 1 in [ i ]
        • Os demais casos são análogos;
    • Semântica Formal Segurança e Liveness
      • Métodos de exclusão de configurações pode ser usado para provar que dois processos não podem estar simultaneamente no mesmo estado:
        • Ex: Na aplicação anterior, dois clientes não podem estar ao mesmo tempo em suas regiões críticas, uma vez que : ( MUTEX  in [ i ]=1  in [ j ]=1  i  j ) = false
    • Semântica Formal Segurança e Liveness
      • Provando deadlocks
        • Prova mais difícil que em comunicação assíncrona;
        • Processo pode ser bloqueado nas operações de entrada e saída;
        • Um processo está bloqueado se está executando um comnado de comunicação que ainda não foi casado;
          • Todo comando de comunicação é potencialmente uma fonte de deadlocks ;
          • A maioria das vezes o bloqueio é temporário;
    • Semântica Formal Segurança e Liveness
      • Provando deadlocks (cont.)
        • Configuração potencialmente blocante (CPB) :
          • Todos os processos estão efetuando uma operação de comunicação;
          • As pré-condições das várias operações de comunicação são verdadeiras;
        • Condições para liberdade de d eadlock ;
          • CPB não existe, ou;
          • CPB existe, e sempre há um par de operações de comunicação que casam;
    • Semântica Formal Segurança e Liveness
      • Propriedades de Liveness
        • Dependem do escalonamento das operações de entrada e saída ;
        • Política de escalonamento incondicionalmente justa :
          • Uma vez que o processo atinge os comandos de entrada e sáída, lá permanecem até que sejam executados;
    • Semântica Formal Segurança e Liveness
      • Propriedades de Liveness
        • Comunicação guardada:
          • Escalonamento fortemente justo;
          • Condições booleanas referem-se somente a variáveis locais;
            • Uma vez verdadeiras, sempre verdadeiras;
    • II. Memória Distibuída Cap. 7 Passagem de Mensagens Síncrona ( Aplica ções ) Fco. Heron de Carvalho Jr., Msc. fhcj @ poli .upe.br
    • Aplica ções a Estudar
      • Redes de Filtros ;
        • Geração de números primos (a peneira de Eratosthenes);
      • Algoritmos Sistólicos ( Interação de Processos );
        • Multiplicação de Matrizes;
      • Clientes e Servidores;
        • Alocação de recursos;
    • Passagem de Mensagens Síncrona (Aplicações)
      • Rede de Filtros
      • ( a peneira de Eratosthenes )
    • Rede de Filtros (A Peneira de Eratosthenes)
      • Implementação Sequencial var num[2:n]:([n-1] 0) var p:=2, i:int {I: p é primo  (  j: 2  j  (p-1) 2 : num[j] = 0  j é primo )} do p*p  n  fa i:=2*p to n by p  num[i] := 1 af p := p + 1 do num[p] = 1  p := p + 1 od od
    • Rede de Filtros (A Peneira de Eratosthenes)
      • Implementação Distribuída ( pipe-line ) Sieve [1]:: var p:=2, i:int # passar pares para Sieve[2] fa i := 3 to n by 2 -> Sieve [2]!i af Sieve [i:2..L]:: ...
    • Rede de Filtros (A peneira de Eratosthenes)
      • Implementação Distribuída ( pipe-line ) Sieve [1] :: ...
      • Sieve [i:2..L]:: var p:int, next:int Sieve [i-1]?p # p é primo do true -> # receber próximo candidato Sieve [i-1]?next # passar adiante se não é múltiplo de p if next mode p  0 -> Sieve [i+1]!next fi od
    • Passagem de Mensagens Síncrona (Aplicações)
      • Algoritmo Sistólico
      • ( Multiplica ção de Matrizes)
    • Algoritmo Sist ólico (Multiplicação de Matrizes)
      • Implementação Distribuída (malha circular, torus ) P[i:1..n,j:1..n]:: var aij, bij, cij: real var new:real, k:int if P[i,j-i]!aij -> P[i,j+i]?aij [] P[i,j+i]?new -> P[i,j-i]!aij fi if P[i-1,i]!aij -> P[i+i,j]?aij [] P[i+1,i]?new -> P[i-1,j]!aij fi cij := aij * bij (...)
    • Algoritmo Sist ólico (Multiplicação de Matrizes)
      • Implementação Distribuída (malha circular, torus ) P[i:1..n,j:1..n]:: (...) fa k := 1 to n-1 -> if P[i,j- 1 ]!aij -> P[i,j+ 1 ]?aij [] P[i,j+ 1 ]?new -> P[i,j- 1 ]!aij fi if P[i-1, 1 ]!aij -> P[i+ 1 ,j]?aij [] P[i+1, 1 ]?new -> P[i- 1 ,j]!aij fi cij = cij + aij * bij af
    • Passagem de Mensagens Síncrona (Aplicações)
      • Clientes e Servidores
      • ( Servidor de Arquivos )
    • Clientes e Servidores (Servidor de Arquivos)
      • File[i:1..n]:: var fname:string, args:outros argumentos var more:bool var local buffer, cache, disk address, etc. do (c:1..m) Client[c]? open ( fname ) -> abre o arquivo Client[c]! open_reply () ; more := true do more -> if Client[c]? read (args) -> handle read; Client[c]! read_reply ( res ) [] Client[c]? write (args) -> handle write; Client[c]! write_reply ( res ) [] Client[c]? close () -> close file ; more := false fi od od
    • Clientes e Servidores (Servidor de Arquivos)
      • Client[i:1..m]:: var serverid :int do (i:1..n) File[i]! open (“foo”) serverid := i; File[i]? open_reply () od … # Para ler File[ serverid ]! read ( access arguments ) File[ serverid ]! read_reply ( results ) … # Para escrever File[ serverid ]! write ( access arguments ) File[ serverid ]! write_reply ( results ) … # Para fechar o arquivo File[ serverid ]! close ()