Qualche esperienza nel mondo reale utilizzando la memoria transazionale del software? [chiuso]

Question

Sembra che ci sia stato un recente crescente interesse per i framework STM (memoria transazionale software) e le estensioni del linguaggio. Clojure in particolare ha un'implementazione eccellente che utilizza MVCC (controllo di concorrenza multi-versione) anziché un registro di commit a rotazione. GHC Haskell ha anche una monade STM estremamente elegante che consente anche la composizione delle transazioni . Infine, in modo da battere un po 'il mio corno, di recente ho implementato un framework STM per Scala che applica staticamente restrizioni di riferimento.

Tutti questi sono esperimenti interessanti, ma sembrano limitarsi alla sola sfera (sperimentazione). Quindi la mia domanda è: qualcuno di voi ha visto o usato STM nel mondo reale? Se è così, perché? Che tipo di benefici ha portato? Che dire delle prestazioni? (Sembra che ci siano molte informazioni contrastanti su questo punto) Utilizzeresti di nuovo STM o preferiresti usare qualche altra astrazione di concorrenza come gli attori?

Answer 1

Ho partecipato allo sviluppo hobbistico del client BitTorrent in Haskell (chiamato evocazione). Utilizza STM abbastanza pesantemente per coordinare thread diversi (1 per peer + 1 per la gestione dello storage + 1 per la gestione complessiva).

Vantaggi: meno blocchi, codice leggibile.

La velocità non è stata un problema, almeno non a causa dell'utilizzo di STM.

Spero che questo aiuti

Answer 2

L'articolo "Memoria transazionale software: perché è solo un giocattolo di ricerca?" non riesce a guardare l'implementazione di Haskell, che è una grande omissione. Il problema per STM, come sottolinea l'articolo, è che le implementazioni devono scegliere tra rendere transazionali tutti gli accessi variabili a meno che il compilatore non possa dimostrarli sicuri (il che uccide le prestazioni) o lasciare che il programmatore indichi quali devono essere transazionali (il che uccide la semplicità e affidabilità). Tuttavia l'implementazione di Haskell utilizza la purezza di Haskell per evitare la necessità di rendere transazionali la maggior parte degli usi variabili, mentre il sistema dei tipi fornisce un modello semplice insieme a un'efficace applicazione delle operazioni di mutazione transazionale. Pertanto, un programma Haskell può utilizzare STM per quelle variabili che sono veramente condivise tra thread, garantendo al contempo che l'uso della memoria non transazionale sia tenuto al sicuro.

Answer 3

Lo usiamo piuttosto regolarmente per le app ad alta concorrenza su Galois (a Haskell). Funziona, è ampiamente utilizzato nel mondo Haskell e non si blocca (anche se ovviamente puoi avere troppe contese). A volte riscriviamo le cose per usare MVars, se abbiamo il design giusto, poiché sono più veloci.

Usalo e basta. Non è niente di grave. Per quanto mi riguarda, STM in Haskell è "risolto". Non c'è altro lavoro da fare. Quindi lo usiamo.

Answer 4

Noi factis research GmbH , stiamo utilizzando Haskell STM con GHC in produzione. Il nostro server riceve un flusso di messaggi su oggetti "quotati" nuovi e modificati da un "data server" clincal, trasforma questo flusso di eventi al volo (generando nuovi oggetti, modificando oggetti, aggregando cose, ecc.) e calcola quali di questi nuovi oggetti dovrebbero essere sincronizzati con iPad collegati. Riceve inoltre input di moduli dagli iPad che vengono elaborati, uniti al "flusso principale". e anche sincronizzato con gli altri iPad. Stiamo utilizzando STM per tutti i canali e le strutture di dati mutabili che devono essere condivisi tra thread. I thread sono molto leggeri in Haskell, quindi possiamo averne molti senza influire sulle prestazioni (al momento 5 per connessione iPad). Costruire una grande applicazione è sempre una sfida e c'erano molte lezioni da imparare ma non abbiamo mai avuto problemi con STM. Ha sempre funzionato come ti aspetteresti ingenuamente. Abbiamo dovuto fare qualche messa a punto delle prestazioni ma STM non è mai stato un problema. (L'80% delle volte cercavamo di ridurre le allocazioni di breve durata e l'utilizzo complessivo della memoria.)

STM è un'area in cui Haskell e il runtime GHC brillano davvero. Non è solo un esperimento e non solo per programmi di giocattoli.

Stiamo costruendo un diverso componente del nostro sistema clincale in Scala e finora abbiamo usato gli attori, ma ci manca davvero STM. Se qualcuno ha esperienza di cosa significhi usare una delle implementazioni di Scala STM in produzione, mi piacerebbe avere tue notizie. : -)

Answer 5

Abbiamo implementato l'intero sistema (database in memoria e runtime) in cima della nostra implementazione STM in C. Prima di questo, avevamo alcuni meccanismi basati su log e lock per gestire la concorrenza, ma questo era un problema da mantenere. Siamo molto contenti di STM poiché possiamo trattare ogni operazione allo stesso modo. Quasi tutti i blocchi potrebbero essere rimossi. Usiamo STM ora per quasi tutto a qualsiasi dimensione, abbiamo anche un attrezzo di gestione della memoria in cima.

Le prestazioni sono buone ma per velocizzare le cose abbiamo ora sviluppato un sistema operativo personalizzato in collaborazione con ETH Zurigo. Il sistema supporta nativamente la memoria transazionale.

Ma ci sono anche alcune sfide causate da STM. Soprattutto con transazioni e hotspot più grandi che causano conflitti di transazione non necessari. Se ad esempio due transazioni inseriscono un elemento in un elenco collegato, si verificherà un conflitto non necessario che avrebbe potuto essere evitato utilizzando una struttura di dati senza blocco.

Answer 6

Attualmente sto usando Akka in alcune ricerche sui sistemi PGAS. Akka è una libreria Scala per lo sviluppo di sistemi concorrenti scalabili che utilizzano Actors, STM e funzionalità integrate di tolleranza agli errori modellate su Erlang " ; Let It Fail / Crash / Crater / ROFL " filosofia. L'implementazione STM di Akka è presumibilmente costruita attorno a un porto Scala dell'implementazione STM di Clojure. Una panoramica del modulo STM di Akka è disponibile qui .