Blocco descrittivo e concorrenza

2

Sto pensando a come si dovrebbe progettare un modello di concorrenza descrittivo per un linguaggio OOP che aiuti a semplificare gli scenari di concorrenza per i programmatori (nessuna attività facile, la concorrenza è difficile).

Ho letto un sacco di memoria transazionale del software, il modello dell'attore, l'immutabilità, ecc. ecc., ma non sembrano nemmeno offrire un modello semplice, e mentre la programmazione funzionale è ottima per alcuni scenari simultanei e paralleli alcune volte semplicemente bisogno di mutare un qualche tipo di stato. Mentre il blocco è considerato negativo da alcuni, è abbastanza facile ragionare su un livello base (fino a quando non si entra in un territorio a deadlock)

Comunque, uno dei modi in cui pensavo che i programmatori fossero in qualche modo più semplici gestire gli scenari multi-thread era che ogni classe è responsabile della propria sicurezza del thread su base metodo / proprietà. Ad esempio, le altre classi possono solo accedere a proprietà e metodi, non possono realmente bloccare tutto in modo specifico, né dovrebbero farlo.

Un modo per renderlo più semplice sarebbe annotare metodi e proprietà per la concorrenza con il loro rientro piuttosto che per il blocco di specifiche. Il compilatore tenterà quindi di dedurre il lock più performante da quello. Quindi assumendo l'atomicità cosa pensi che sarebbero buone annotazioni? e quali sono i potenziali problemi con questo approccio,

Sono consapevole che non è in grado di risolvere tutti gli scenari (come le transazioni) ma dovrebbe aiutare il compilatore a far rispettare l'intento dei programmatori e potrebbe anche essere in grado di mettere in guardia su potenziali scenari di deadlock / corse

Ecco alcuni degli attributi che ho pensato fino ad ora (si noti anche che nessuno di essi è obbligatorio ma strettamente "hint")

<property preference="none|read|write|fair">

   <get access="free|exclusive|shared" 
       load="unknown|many|few" 
       duration="unknown|nano|brief|long"/>

    <set access="free|exclusive|shared|upgradeable" 
       load="unknown|many|few" 
       duration="unknown|nano|brief|long" />

</property>

Quindi, ad esempio, se get e set era impostato su accesso condiviso, si potrebbe finire con un lock reader-writer. (ho bisogno di un attributo per controllare visiblity.) Se la durata di una scrittura è stata impostata su nano, forse userebbe uno spinlock. Se ci sono molte letture e poche scritture, forse il compilatore userebbe un blocco diverso che se ci fossero molte scritture e poche letture ecc ecc.

I metodi possono essere accoppiati in coppie di lettura / scrittura in modo simile alle proprietà (nel caso in cui sia necessario più di un parametro).

Per le proprietà numeriche che di solito si aggiornano in base ad alcune condizioni del suo valore, pensavo anche che invece di passare solo un nuovo valore, si potesse passare un operatore e un importo. In questo modo puoi bloccare, calcolare il nuovo valore, vedere se soddisfa alcune condizioni interne e in tal caso aggiornare.

Ad ogni modo, sto facendo un po 'fatica a venire con buone caratteristiche / notazioni che sono piuttosto facili per un programmatore di comprendere a fondo il proprio ragionamento, qualsiasi aiuto e feedback sono molto apprezzati.

Ci scusiamo per il lungo rant, come ho detto questo non è un argomento facile :)

    
posta Homde 08.04.2011 - 00:22
fonte

2 risposte

2

Il problema con il blocco è che, per definizione, non scala. Solo un thread può bloccare una struttura dati alla volta.

Una migliore soluzione alla concorrenza è generalmente il modello dell'attore, o qualche sua variante. Ovvero, condividere lo stato passando messaggi, non bloccando. Erlang è un ovvio esempio di quel paradigma, ma se non ti piacciono le lingue funzionali, potresti voler controllare Google Go, che è un linguaggio procedurale che implementa un meccanismo simile di trasmissione dei messaggi (chiamato canali, in combinazione con il suo leggero discussioni, chiamate goroutine).

    
risposta data 08.04.2011 - 05:21
fonte
0

MS ha già aggiunto helper per il parallelismo automatico su .NET. link

Alcuni problemi di concurrency devono ancora essere trattati come i blocchi di file, ma la memoria non è un problema AFAIK. Lo ha anche il fondamento del flusso di lavoro. Ancora una volta, ci sono alcuni limiti e può diventare piuttosto peloso. Se cerchi forum MS sul flusso di lavoro con il mio nome, puoi trovare alcuni esempi di cattiveria.

    
risposta data 08.04.2011 - 04:04
fonte

Leggi altre domande sui tag