[Python] È stato rilasciato Python 3.5
Manlio Perillo
manlio.perillo a gmail.com
Gio 17 Set 2015 11:28:20 CEST
2015-09-15 14:29 GMT+02:00 Nicola Larosa <nico a teknico.net>:
> [...]
>
> Ecco una bella spiegazione della differenza tra preemptive
> multithreading, eventi asincroni e coroutine (gevent, Eventlet). Scritta
> da un core dev di Twisted, non è difficile immaginare la preferenza: ;-)
>
> Unyielding <https://glyph.twistedmatrix.com/2014/02/unyielding.html>
>
>
Non capisco l'esempio che fa riguardo il trasferimento del denaro, a meno
che mi stia perdendo qualcosa.
Glyph scrive:
> "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."
Come sarebbe a dire che non stiamo aspettando che
sufficient_funds_for_withdrawl completi?
La funzione controlla il valore restituito da quella funzione, quindi è
ovvio che *dobbiamo* aspettare che completi.
Inoltre cosa intende quando dice che "se non aspettiamo che le funzioni
completano, queste non causano la funzione transfer di interferire con se
stessa"?
Per come leggo quell'esempio, la versione con yield equivale a
*serializzare* le varie operazioni che possono causare problemi se eseguite
in modo concorrente.
Ossia, l'esempio è equivalente a mettere un bel mu.Lock() all'inizio della
funzione e mu.Unlock() prima di chiamare update_balances.
Per quel che ricordo, in Twisted quel lock è globale (come il GIL di
Python), quindi se quella funzione viene eseguita in una applicazione web,
finchè il mutex è attivo *nessun* altra funzione può essere eseguita, anche
se magari riceviamo una richiesta HTTP che non deve fare nessuna
transazione finanziaria.
Per farla breve: per risolvere i problemi della concorrenza eliminiamo del
tutto la concorrenza, tranne nei punti in cui lo permettiamo esplicitamente.
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.
Ciao Manlio
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150917/0c4ec2a4/attachment.html>
Maggiori informazioni sulla lista
Python