Quali sono gli svantaggi di realizzare un'implementazione runtime JavaScript multi-thread? [chiuso]

Ho lavorato su un'implementazione runtime JavaScript multi-thread per la scorsa settimana. Ho una prova del concetto realizzata in C ++ usando JavaScriptCore e boost.

L'architettura è semplice: quando il runtime termina la valutazione dello script principale si avvia e si unisce a un pool di thread, che inizia a selezionare le attività da una coda di priorità condivisa, se due attività tentano di accedere contemporaneamente a una variabile viene contrassegnata come atomica e si contendono l'accesso .

Il problema è che quando mostro questo progetto a un programmatore JavaScript ricevo un feedback estremamente negativo e non ho idea del perché. Anche in privato, tutti dicono che JavaScript deve essere a thread singolo, che le librerie esistenti dovrebbero essere riscritte e che i gremlin genereranno e mangeranno ogni essere vivente se continuo a lavorare su questo.

Inizialmente avevo anche un'implementazione coroutine nativa (usando contesti boost), ma dovevo abbandonarla (JavaScriptCore è pedante riguardo allo stack) e non volevo rischiare la loro ira, quindi ho deciso di non menzionarlo.

Cosa ne pensi? JavaScript è pensato per essere single thread e dovrebbe essere lasciato solo? Perché tutti sono contrari all'idea di un runtime JavaScript simultaneo?

Modifica: il progetto è ora su GitHub , sperimentalo tu stesso e fammi sapere cosa ne pensi.

Di seguito è riportato un quadro delle promesse in esecuzione su tutti i core della CPU in parallelo senza contese:

1) Il multithreading è estremamente difficile, e sfortunatamente il modo in cui hai presentato questa idea finora implica che stai sottovalutando gravemente quanto sia dura.

Al momento, sembra che tu stia semplicemente "aggiungendo discussioni" al linguaggio e ti preoccupi di come renderlo corretto e performante in seguito. In particolare:

se due attività tentano di accedere contemporaneamente a una variabile, questa viene contrassegnata come atomica e si contendono l'accesso.
...
Sono d'accordo che le variabili atomiche non risolveranno tutto, ma lavorare su una soluzione per il problema di sincronizzazione è il mio prossimo obiettivo.

Aggiungere thread a Javascript senza una "soluzione per il problema di sincronizzazione" sarebbe come aggiungere numeri interi a Javascript senza una "soluzione per il problema dell'aggiunta". È così fondamentale per la natura del problema che praticamente non ha nemmeno senso discutere se valga la pena aggiungere il multithreading senza una soluzione specifica in mente, non importa quanto potremmo volerlo.

Inoltre, rendere atomiche tutte le variabili è il genere di cose che probabilmente farà sì che un programma multithread abbia prestazioni peggiori rispetto alla sua controparte single-threaded, il che rende ancora più importante testare effettivamente le prestazioni su programmi più realistici e vedere se stai guadagnando qualcosa o meno.

Inoltre, non mi è chiaro se stai cercando di tenere nascosti i thread dal programmatore node.js o se hai intenzione di esporli ad un certo punto, creando effettivamente un nuovo dialetto di Javascript per la programmazione multithread. Entrambe le opzioni sono potenzialmente interessanti, ma sembra che tu non abbia ancora deciso quale stai puntando.

Quindi, al momento, stai chiedendo ai programmatori di prendere in considerazione il passaggio da un ambiente a thread singolo a un ambiente multithread nuovo di zecca che non ha soluzione per il problema di sincronizzazione e nessuna prova che migliora le prestazioni del mondo reale e apparentemente non ha alcun piano per risolvere tali problemi.

Questo è probabilmente il motivo per cui le persone non ti prendono sul serio.

2) La semplicità e la robustezza del singolo loop di eventi è un enorme vantaggio.

I programmatori Javascript sanno che il linguaggio Javascript è "sicuro" dalle condizioni di gara e da altri bug estremamente insidiosi che affliggono tutta la programmazione realmente multithread. Il fatto che abbiano bisogno di argomenti forti per convincerli a rinunciare al fatto che la sicurezza non li rende di mentalità chiusa, li rende responsabili.

A meno che tu non riesca in qualche modo a mantenere quella sicurezza, chiunque voglia passare a un nodo multithread.js probabilmente starebbe meglio passare a una lingua come Go progettata da zero per le applicazioni multithread.

3) Javascript supporta già i "thread in background" (WebWorkers) e la programmazione asincrona senza esporre direttamente la gestione dei thread al programmatore.

Queste funzionalità risolvono già molti dei casi d'uso comuni che interessano i programmatori Javascript nel mondo reale, senza rinunciare alla sicurezza del singolo loop di eventi.

Hai in mente casi d'uso specifici che queste funzionalità non risolvono e per cui i programmatori Javascript vogliono una soluzione? In tal caso, sarebbe una buona idea presentare il tuo node.js multithread nel contesto di quel caso d'uso specifico.

PS Cosa mi convincerebbe a provare a passare a un'implementazione node.js multithread?

Scrivi un programma non banale in Javascript / node.js che pensi possa trarre vantaggio da un vero multithreading. Eseguire test delle prestazioni su questo programma di esempio nel nodo normale e nel nodo multithread. Dimostrami che la tua versione migliora in modo significativo le prestazioni di runtime, la reattività e l'utilizzo di più core, senza introdurre alcun bug o instabilità.

Una volta che lo hai fatto, penso che vedrai le persone molto più interessate a questa idea.

Indovina qui per dimostrare un problema nel tuo approccio. Non riesco a testarlo con la vera implementazione in quanto non esiste alcun collegamento da nessuna parte ...

Direi che è perché gli invarianti non sono sempre espressi dal valore di una variabile e 'una variabile' non è sufficiente per essere l'ambito di un blocco nel caso generale. Ad esempio, immagina di avere un invariante a+b = 0(il saldo di una banca con due conti). Le due funzioni seguenti assicurano che l'invariante sia sempre tenuto alla fine di ogni funzione (l'unità di esecuzione in JS a thread singolo).

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

Ora, nel tuo mondo multithread, cosa succede quando due thread vengono eseguiti withdrawe depositallo stesso tempo? Grazie Murphy ...

(Potresti avere un codice che tratta + = e - = specialmente, ma questo non è di aiuto. Ad un certo punto, avrai uno stato locale in una funzione e senza alcun modo per "bloccare" due variabili contemporaneamente il tuo invariante essere violato).

EDIT: se il tuo codice è semanticamente equivalente al codice Go su https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a , il mio commento è accurato ;-)

Circa un decennio fa Brendan Eich (l'inventore di JavaScript) ha scritto un saggio chiamato Threads Suck , che è sicuramente uno dei pochi documenti canonici della mitologia del design di JavaScript.

Se è corretto è un'altra domanda, ma penso che abbia avuto una grande influenza sul modo in cui la comunità JavaScript pensa alla concorrenza.

L'accesso atomico non si traduce in un comportamento thread-safe.

Un esempio è quando una struttura di dati globale deve essere non valida durante un aggiornamento, ad esempio la ripetizione di un hashmap (ad esempio quando si aggiunge una proprietà a un oggetto) o l'ordinamento di un array globale. Durante quel periodo non puoi consentire a nessun altro thread di accedere alla variabile. Ciò significa sostanzialmente che è necessario rilevare l'intero ciclo di lettura-aggiornamento-scrittura e bloccarlo. Se l'aggiornamento non è banale, finirà per arrestare il territorio problematico.

Javascript è stato single threading e sandbox dall'inizio e tutto il codice è stato scritto tenendo conto di questi presupposti.

Questo ha un grande vantaggio per quanto riguarda i contesti isolati e consentire l'esecuzione di 2 contesti separati in thread diversi. Voglio anche dire che le persone che scrivono javascript non devono sapere come gestire le condizioni di gara e vari altri pitfal multi-thread.

Il tuo approccio migliorerà significativamente le prestazioni?

Dubbioso. Hai davvero bisogno di dimostrarlo.

Il tuo approccio renderà più semplice / veloce la scrittura del codice?

Sicuramente no, il codice multithread è molte volte più difficile da ottenere rispetto al codice a thread singolo.

Il tuo approccio sarà più solido?

Deadlock, condizioni di gara ecc. Sono un incubo da risolvere.

L'implementazione non riguarda solo l'introduzione della concorrenza, ma piuttosto l'introduzione di un modo specifico per implementare la concorrenza, ovvero la concorrenza per stato mutabile condiviso. Nel corso della storia le persone hanno usato questo tipo di concorrenza e questo ha portato a molti tipi di problemi. Ovviamente puoi creare semplici programmi che funzionano perfettamente con l'utilizzo della concorrenza condivisa dello stato mutabile, ma il vero test di qualsiasi meccanismo non è quello che può fare, ma può ridimensionarsi man mano che il programma diventa complesso e sempre più funzionalità vengono aggiunte al programma. Ricorda che il software non è una cosa statica che costruisci una volta e che ne hai fatto, ma continua a evolversi nel tempo e se qualsiasi meccanismo o concetto può "

Puoi esaminare altri modelli di concorrenza (ad es. Il passaggio di messaggi) per aiutarti a capire che tipo di vantaggi offrono questi modelli.

Questo è necessario. La mancanza di un meccanismo di concorrenza di basso livello nel nodo js limita le sue applicazioni in campi come la matematica e la bioinformatica, ecc ... Inoltre, la concorrenza con i thread non è necessariamente in conflitto con il modello di concordanza predefinito utilizzato nel nodo. Esistono semantiche ben note per il threading in un ambiente con un ciclo di eventi principale, come i framework dell'interfaccia utente (e nodejs), e tuttavia sono decisamente eccessivamente complesse per la maggior parte delle situazioni che hanno ancora usi validi.

Certo, la tua app web media non richiederà thread, ma prova a fare qualcosa di un po 'meno convenzionale e la mancanza di una primitiva di concorrenza di basso livello ti sposterà rapidamente a qualcos'altro che la offre.

Credo davvero che sia perché è un'idea diversa e potente. Stai andando contro i sistemi di credenze. Le cose diventano accettate o popolari attraverso gli effetti della rete non sulla base del merito. Inoltre, nessuno vuole adattarsi a un nuovo stack. Le persone rifiutano automaticamente cose troppo diverse.

Se riesci a trovare un modo per trasformarlo in un normale modulo npm che sembra improbabile, allora potresti convincere alcune persone a usarlo.