In quali modi significativi Erlang previene le condizioni di gara nella programmazione concorrente?

11

Leggendo la concorrenza in Erlang , mi ricorda kitkit di concorrenza di Akka . Entrambi ti forniscono gli strumenti per prevenire o limitare le condizioni di gara . Ma puoi inviare collegamenti a dati mutabili ad altri processi usando il toolkit di Akka, che è ancora pericoloso. Vedo Akka come uno strumento utile, ma non fornisce protezione contro l'accesso fuori ordine a oggetti e dati che portano a condizioni di competizione, deadlock e / o fame. Non ti impedisce di scrivere codice non sicuro nel modo in cui Java o C # ti proteggono dallo scrivere la maggior parte dei tipi di perdite di memoria che puoi scrivere in C ++ (puoi ancora creare perdite di memoria in Java ingannando il garbage collector, ma è meno di un problema piuttosto che dover ricordare di liberare ogni byte che si assegna).

Erlang garantisce un grado di correttezza, prestazioni e robustezza nella programmazione concorrente? Penso che i sistemi operativi forniscano protezione quando accedono alle risorse del sistema (presupponendo che gli autori dei driver abbiano fatto bene il loro lavoro). I database ACID forniscono protezione per letture e aggiornamenti. Quindi sembra che questo sia un problema risolvibile. O una soluzione generica sicura cancellerebbe i guadagni in termini di prestazioni forniti dalla concorrenza? Altri linguaggi o toolkit forniscono il tipo di sicurezza concorrente che Erlang fa (o non fa)?

Questa è una domanda successiva a @ Il commento di Malfist sulla risposta di @ user1249 a Quale linguaggio di programmazione genera meno bug difficili da trovare? .

    
posta GlenPeterson 22.01.2013 - 14:34
fonte

1 risposta

19

Ci sono alcune cose che Erlang fa per aiutarle.

  • I dati sono immutabili, quindi nessun dato razziale
  • OTP gen_servers e gen_fsm forniscono un modello molto ben testato per i server
  • I supervisori consentono il recupero da arresti anomali
  • I processi
  • sono piccoli ed economici
  • La memoria viene allocata in base al processo (nessun GC si blocca)
  • l'erlang VM è ottimizzato per lavorare con carichi molto pesanti
  • Il software può essere aggiornato al volo, quindi nessun downtime di aggiornamento

La cosa importante qui è che in Erlang non esiste uno stato condiviso che potrebbe richiedere un blocco, quindi non c'è bisogno di serrature. È un linguaggio brillante per applicazioni soft real-time che non necessitano di tempi di inattività, elevata tolleranza agli errori e concorrenza

    
risposta data 22.01.2013 - 16:13
fonte

Leggi altre domande sui tag