2010-03-17 18 views
5

Lettura (sufficiente per ottenere la codifica) tramite Erlang Programming e Programming Erlang.Ordine di tempo dei messaggi

Una domanda, che è così semplice come sembra:

Se si dispone di un processo Pid1 sulla macchina m1 miliardi e milioni di messaggi vengono inviati a Pid1, sono messaggi gestiti in parallelo da quel processo (ottengo l'impressione n.) e (risposta di seguito)

c'è qualche garanzia di ordine durante l'elaborazione dei messaggi? vale a dire. Ricevuto nell'ordine inviato? In tal caso, in che modo viene gestita l'inclinazione dell'orologio in situazioni di traffico elevato per l'ordine?

Provenendo da C/Pool di thread/Sfondo Stato condiviso ... Voglio ottenere questo concreto. Comprendo la distribuzione di un'applicazione, ma voglio garantire che le "ossa grezze" siano ciò che mi aspetto prima di creare processi e distribuire il carico di lavoro.

Inoltre, Ho ragione di pensare che il mondo intero sta attualmente sfogliando i testi Erlang;)

risposta

10

Se il processo A invia due messaggi per elaborare B, i due messaggi sono garantiti per arrivare nell'ordine in cui sono inviati.

Se il processo A invia un messaggio per elaborare B e quindi un messaggio per elaborare C, non è possibile garantire l'ordine in cui vengono ricevuti.

Analogamente, se i processi A & B inviano messaggi a C, non è possibile garantire l'ordine in cui i messaggi vengono ricevuti.

È una proprietà fondamentale del modello che passa il messaggio, l'ordine dei calcoli in diversi processi non è definito, si può solo parlare in maniera significativa dell'ordine in cui è coinvolto un invio di messaggio. Una conseguenza delle regole precedenti è che se A invia un messaggio a C, quindi un messaggio a B, e al ricevimento del messaggio B invia a C, allora C può ricevere i due messaggi in qualsiasi ordine.(In pratica, sospetto che non si inverta mai su un singolo nodo, ma potrebbe facilmente accadere se i tre processi si trovano su nodi diversi.)

+0

+1, una buona risposta valida. Il mio pensiero sul passaggio dei messaggi è molto più chiaro ora che se A e B inviano molti messaggi a C, allora nessun ordine (dell'unione dei messaggi di A e B) è concreto. Qualcosa da considerare nel "posizionamento delle preoccupazioni" nel design, penso. –

+0

Joe Armstrong fa un'analogia (http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html) che mi piace molto. L'ordine garantisce di essere esattamente lo stesso di un gruppo di persone che parlano tra loro. – cthulahoops

+0

Ottimo link, grazie! –

2

I messaggi non vengono gestiti in parallelo; è solo un processo, dopo tutto.

Come ordine messaggistico: la coda dei messaggi viene scansionata in "tempi" (dal più vecchio al più recente). I penso Ricordo una discussione sulla mailing list molto tempo fa in cui qualcuno ha chiarito che il timestamp è quello dell'origine dei messaggi (cioè il momento in cui è stato inviato), ma non riesco a ricordare troppo chiaramente e posso trovare riferimenti a quello online

Si noti che l'istruzione receive può eseguire la corrispondenza in testa alla coda dei messaggi in entrata, il che ovviamente consentirebbe a un destinatario di prelevare i messaggi in arrivo dall'ordine (temporale).

+0

+1, grazie a punta. Mantenere le schede sull'ordine temporale è un'opzione. Suppongo che l'ordine assoluto sia quasi impossibile. Buona risposta! I miei messaggi arriveranno con una risposta al processo di origine. Eppure, Erlang sincronizza gli orologi? –

1

Per il erlang reference manual:

[Ricevere] riceve i messaggi inviati al processo utilizzando l'operatore di trasmissione (!). I pattern Pattern sono sequenzialmente abbinati al primo messaggio nell'orario nella cassetta postale, quindi al secondo e così via.

I messaggi vengono elaborati in serie per processo.

+0

+1, ah eccolo: P Cosa succede se il timestamp è "tempo inviato" e gli orologi dei nodi hanno l'inclinazione; In un ambiente ad alto traffico è importante, le VM/lib di Erlang tengono conto di questo? –