<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-09-15 14:29 GMT+02:00 Nicola Larosa <span dir="ltr"><<a href="mailto:nico@teknico.net" target="_blank">nico@teknico.net</a>></span>:<br><div>> [...] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Ecco una bella spiegazione della differenza tra preemptive<br>
multithreading, eventi asincroni e coroutine (gevent, Eventlet). Scritta<br>
da un core dev di Twisted, non è difficile immaginare la preferenza: ;-)<br>
<br>
Unyielding <<a href="https://glyph.twistedmatrix.com/2014/02/unyielding.html" rel="noreferrer" target="_blank">https://glyph.twistedmatrix.com/2014/02/unyielding.html</a>><br>
<br></blockquote><div><br></div><div>Non capisco l'esempio  che fa riguardo il trasferimento del denaro, a meno che mi stia perdendo qualcosa.</div><div><br></div><div>Glyph scrive:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">"So now we have a trivially concurrent, correct version of this routine, although we did have to update it a little. Regardless of what sufficient_funds_for_withdrawl, deposit and withdrawl do - even if they do network I/O - we know that we aren’t waiting for any of them to complete, so they can’t cause transfer to interfere with itself."</blockquote><div><br></div><div><br></div><div>Come sarebbe a dire che non stiamo aspettando che sufficient_funds_for_withdrawl completi?</div><div>La funzione controlla il valore restituito da quella funzione, quindi è ovvio che *dobbiamo* aspettare che completi.</div><div><br></div><div>Inoltre cosa intende quando dice che "se non aspettiamo che le funzioni completano, queste non causano la funzione transfer di interferire con se stessa"?</div><div><br></div><div>Per come leggo quell'esempio, la versione con yield equivale a *serializzare* le varie operazioni che possono causare problemi se eseguite in modo concorrente.</div><div>Ossia, l'esempio è equivalente a mettere un bel mu.Lock() all'inizio della funzione e mu.Unlock() prima di chiamare update_balances.</div><div>Per quel che ricordo, in Twisted quel lock è globale (come il GIL di Python), quindi se quella funzione viene eseguita in una applicazione web,</div><div>finchè il mutex è attivo *nessun* altra funzione può essere eseguita, anche se magari riceviamo una richiesta HTTP che non deve fare nessuna transazione finanziaria.</div><div><br></div><div>Per farla breve: per risolvere i problemi della concorrenza eliminiamo del tutto la concorrenza, tranne nei punti in cui lo permettiamo esplicitamente.</div><div><br></div><div>La soluzione corretta è invece quella di serializzare solo la transazione finanziaria che convolge A e B, e permettere l'esecuzione concorrente di qualsiasi altra operazione incluse le transazioni finanziare che con coinvolgono A e B.</div><div><br></div><div></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Ciao  Manlio</div></div>