Como é realizada a comunicação entre processos Cite as vantagens é desvantagens?

IPC em Unix

IPC permite:

• transfer�ncia de dados;
• partilha de dados;
• notifica��o de eventos;
• partilha de recursos especializada;
• controle de processos: debugger quer tomar conta dos eventos de outro processo.

IPC em Unix Original: Sinais

Sinais v�m desde Unix original:

• mecanismo ass�ncrono de notifica��o;
• muitos com significado pr�definido (SIGUSR1 e SIGUSR2);
• kill() envia sinais para outro processo.
• sigpause() espera por sinal.
• sigaction() define handler.
• S�o caros porque emissor tem que fazer syscall e kernel tem que mexer na pilha do receptor.
• Banda limitada: apenas 31 em SVR4 e 4.3BSD, 64 em AIX, Linux.
• �teis para notifica��o.

Pipes

FIFO n�o-estruturado e unidirecional:

• Escrever no fim e ler do princ�pio;
• Escritores bloqueam se pipe cheio e leitores se vazio.
• pipe() retorna dois file-descriptores, um para ler e outro para escrever. Descriptores podem ser passados entre processos.
• Usados pela shell, tem algumas limita��es:
  • n�o suportam broadcast;
  • n�o conhecem limites de mensagem;
  • n�o se pode especificar o leitor

Mais Pipes

Implementa��o varia:

• Tradicionalmente: inode e entrada na tabela de ficheiros com pipe.
• BSD usa sockets, SVR4 usa streams, Linux usa c�digo especializado com sem�foro e kmalloc() (vd. fs/pipe.c).

Named pipes: mknod � usado para criar o pipe, que depois � acess�vel a processos.

• Vantagens: persist�ncia, acesso para qq processo.
• Desvantagens: t�m que ser removidos, n�o s�o t�o seguros, consomem mais recursos, mais complicados de criar.
• Linux usa o mesmo c�digo, e pipes pertencem a um pipefs onde � montado o arquivo.

Controle de Processos

ptrace(cmd, pid, addr, data).

• Permite a um processo:
  • ler ou escrever no espa�o de um filho (incluindo �rea-u);
  • mexer nos registos;
  • criar watchpoints no espa�o de endere�amento;
  • interceptar sinais;
  • criar ou alterar watchpoints;
  • continuar a execu��o de um filho parado;
  • andar passo a passo;
  • matar o filho;
• cmd == 0 � usado pelo filho para indicar que est� controlada por ptrace(), alterando comportamento para sinais e para fork()

ptrace em ac��o

• Parente usa wait() para esperar eventos que mudam o estado do filho.
• Filho envia SIGCHLD quando acontece alguma coisa.
• exec no filho resulta em SIGTRAP que pode ser controlada pelo pai.
• Quando SIGCHLD chega pai usa ptrace() para controlar.

Limita��es:

• s� pode controlar filhos imediatos;
• n�o permite apanhar processos em andamento;
• extremamente ineficiente;
• problemas com programs setuid().

IPC em SYSV

SYSV suporta sem�foros, filas de mensagens, e mem�ria partilhada

Cada recurso tem os seguintes atributos:

• Chave: inteiro que identifica a inst�ncia do recurso.
• Criador: UID e GID do processo que creou
• Dono: pode ser <> do anterior.
• Permiss�es.

get cria o recurso, cft controla com STAT, SET, RMID.

Cada recurso tem uma tabela de tamanho fixa.

Ver ipc em Linux.

Sem�foros em SYSV

• semid = semget(key, count, flag) array de count sem�foros.
• status = semop(semid, sops, nsops), onde sops aponta para um array de opera��es. Opera��o pode ser incrementar (>0), esperar at� sem�foro estar a 0 (=0), ou esperar que o valor seja maior ou igual ao valor absoluto (<0) e depois subtrair esse valor.
• Todas as opera��es avan�am ou bloqueiam. Nenhuma outra opera��o pode executar em paralelo.
• IPC_NOWAIT evita bloqueio.
• Kernel mant�m UNDO LIST para o caso do processo sair.

IPC em Mach

Troca de Mensagens � o mecanismo fundamental de comunica��o:

• Mensagens podem variar entre alguns bytes e um espa�o de endere�amento.
• Comunica��o deve ser segura.
• Comunica��o ligada a gest�o de mem�ria.
• Comunica��o entre user tasks, e com o kernel.
• Suportar o modelo cliente-servidor
• Interface pode ser generalizada para ambiente distribuido.

Bastantes melhoramentos em Mach 3.0.

Portas em Mach

Tasks tem direitos sobre portas de send e de receive (apenas a dono): comunica��o muitos-para-um.

Mensagens podem ser:

• Simples: dados ordin�rios que n�o s�o interpretados pelo kernel;
• Complexa:
  • dados ordin�rios, +
  • mem�ria out-of-line que � passada por refer�ncia (COW), +,
  • direitos de envio ou recep��o para portas.
  Kernel interpreta mensagens complexas.
• Cada porta tem um contador de refer�ncias.

Mais Portas

• Cada direito ou capacidade, � um nome para a porta. Nomes s�o inteiros e locais a tasks.
• Objectos do kernel s�o representado por uma porta. Acesso a essa porta permite ao dono fazer opera��es no objecto. O kernel tem os direitos de recep��o para essas portas.
• Cada porta tem uma fila de mensagens finita. Emissores bloqueiam quando a fila enche.

Portas, Tasks, e Threads

• Por Task:
  • Cada task tem uma porta task_self para ela pr�pria;
  • Pode enviar para bootstrap que fornece acesso ao name server.
  • uma porta de exception.
• Por Thread:
  • direitos de envio para self;
  • direitos de recep��o para reply;
  • uma porta de exception.
• Todos as threads numa task partilham direitos.

Mensagens em Mach

Mensagens podem ser locais ou por rede (atrav�s de netmsgserver):

• Cabe�alho cont�m: Tipo: simples ou complexo; Tamanho: mensagegem inc. cabe�alho; Destino: uma porta; Resposta: uma porta, se necess�rio; ID: ao cuidado do usu�rio.
• Components cont�m dados e descriptor: nome: tipo de dados, eg, mem�ria interna, direitos de envio ou recep��o, escalar (byte, string, int de 16/32 bits, ...). Tamanho: tamanho de cada item de dados; N�mero: de items; Flags: dados s�o "in-line" ou "out-of-line" e se a mem�ria ou os direitos devem ser deadlocados.

Estrutura de uma Mensagem

Interface

Tr�s fun��es:

• • msg_send() envia sem esperar;
  • msg_rcv() espera por mensagens;
  • msg_rpc() envia e espera por uma resposta que pode vir no pr�prio buffer.
    • Optimiza��o de msg_send() + msg_rcv().
    • Originalmente o header tem o tamanho m�ximo da msg que pode receber.
    • No fim o header tem o tamanho da mensagem.
• Todas opera��es t�m TIMEOUT.

Implementa��o de Portas em Mach

Cada porta � uma fila protegida de mensagens no kernel:

• contador de refer�ncias para a porta;
• ptr para a task que tem direitos de recepc�o;
• nome local no receptor;
• ptr para porta backup;
• lista dupl. ligada de mensagens;
• fila de emissores bloqueados;
• fila de threads receptores bloqueados;
• lista de todas as tradu��es;
• ptr para um "port set";
• n�m. de mensagens na fila;
• n�m max. permitido ("backlog").

Tradu��es de Portas

Tradu��o � <task,port,local_name,type>:

• sender usa <task,local_name> (TL);
• receiver usa <task,port> (TP);
• tasks t�m que encontrar todos os direitos para a porta quando ela � dealocada;
• direitos s�o limpos quando a porta � destru�da.

Passagem de Mensagens em Mach

Emiss�o:

1. Emissor cria mensagem;
2. chama msg_send() do kernel;
3. kernel copia mensagem e:
   1. se thread est� � espera � acordado e recebe;
   2. se lista cheia emissor bloqueia;
   3. sen�o mensagem colocada na fila;

Recep��o:

1. receptor chama msg_rcv();
2. kernel chama msg_dequeue();
3. kernel copia para receptor.

Portas em Mensagens

• Se emissor espera resposta, envia direitos para porta usando campo reply port na mensagem.
• Quando nova porta chega a task kernel traduz:
  1. se porta j� existe ok;
  2. aloca novo �ndice (< int) e cria nova tradu��o.
• Servidor de nomes passa direitos de acesso a portas de servidores:
  

Mem�ria Out-of-Line

• msg_send() chama msg_copyin():
  1. modifica mapeamentos das p�g para ser RO e COW;
  2. cria mapa temp. no kernel.
• msg_rcv() chama msg_copyout():
  1. aloca espa�o no receptor;
  2. copia entradas do mapa temp;
  3. remove mapa.
• Quando algu�m tenta mexer na p�gina, PF e kernel chama "fault handler":
  1. cria uma nova c�pia da p�gina;
  2. muda mapa do processo que falhou;
  3. se puder, permite ao outro processo escrever na p�gina original.
• Se emissor usar deallocate, msg_copyin() e msg_copyout() apenas passam as p�ginas.

Controle de Portas

• Mensagens podem ser enviadas no caminho lento (colocar na fila) ou caminho r�pido (handoff scheduling).
• backlog � o limite configur�vel de mensagens numa porta.
• Notifica��es: mensagens enviadas para informar uma task de eventos:
  • NOTIFY_PORT_DESTROYED: qdo porta destru�da msg. � enviada para porta backup;
  • NOTIFY_PORT_DELETED: qdo porta destru�da msg. � enviada para todos os processos com direito de envio.
  • NOTIFY_MSG_ACCEPTED: se msg_send() usar SEND_NOTIFY, msg. � colocada mesmo que fila cheia e qdo msg. retirada da fila emissor kernel envia-lhe NOTIFY_MSG_ACCEPTED.

Opera��es sobre Portas em Mach

Passagem de Mensagem em Rede

netmsgserver permite extens�o para rede:

• Usa proxy ports para "enganar" clientes, e comunica com outros netmsgserver para distribuir o sistema.
• Poss�vel porque cliente tem apenas acesso a nome local para a porta, e porque emissores s�o an�nimos: o emissor pode enviar apenas o direito de acesso a uma porta de resposta.

Mach 3.0

• Dificil dealocar send rights, pq n�o se sabe que threads est�o a usar o direito: send-once rights.
• Apenas envia notifica��es a processos que as pediram.
• Kernel mant�m um contador de refer�ncia a direitos por task. Quando o contador vai a 0, pode dealocar.

Como é realizada a comunicação entre processos Cite as vantagens é desvantagens?

Como é feita a comunicação entre processos?

Como funciona a comunicação do sistema operacional?

Quais são as vantagens é desvantagens de criar uma área de memória compartilhada?