Author: Maciej Fijalkowski <fij...@gmail.com> Branch: extradoc Changeset: r4958:643f8e36f6a8 Date: 2013-03-15 09:54 -0700 http://bitbucket.org/pypy/extradoc/changeset/643f8e36f6a8/
Log: some progress and slidification diff --git a/talk/pycon2013/pypy_without_gil/talk.rst b/talk/pycon2013/pypy_without_gil/talk.rst --- a/talk/pycon2013/pypy_without_gil/talk.rst +++ b/talk/pycon2013/pypy_without_gil/talk.rst @@ -120,64 +120,53 @@ * tons of optimizations possible +How do I use it? +---------------- +* just like with the GIL +* ``__pypy__.thread.atomic`` -- __pypy__.thread.atomic +:: + with atomic: + print "hello", username - * with atomic: - print "hello", username +* the illusion of serialization - * the illusion of serialization +STM - low level +--------------- +* STM = Software Transactional Memory -Lower level: STM ---------------------------- - -- pypy and not cpython? - - -- STM = Software Transactional Memory - - -- Basic idea: each thread runs in parallel, but everything it does is +* Basic idea: each thread runs in parallel, but everything it does is in a series of "transactions" +* A transaction keeps all changes to pre-existing memory "local" -- A transaction keeps all changes to pre-existing memory "local" +* The changes are made visible only when the transaction "commits" -- The changes are made visible only when the transaction "commits" +STM - low level (2) +------------------- - -- The transaction will "abort" if a conflict is detected, and +* The transaction will "abort" if a conflict is detected, and it will be transparently retried -- Non-reversible operations like I/O turn the transaction "inevitable" +* Non-reversible operations like I/O turn the transaction "inevitable" and stop progress in the other threads -- __pypy__.thread.last_abort_info() -> traceback-like information +* __pypy__.thread.last_abort_info() -> traceback-like information +Alternative - HTM +----------------- -- (GC-supported structure: when we want to modify a pre-existing object, - we first copy it into "local" memory, and when we commit, it becomes - the newer version of the old pre-existing object; we end up with a - chained list of versions, and we have to make sure we always use the - latest one. We rely on GC major collections to free them eventually.) - - -- alternative: HTM...? - +XXX Higher level: not threads --------------------------- - -- xxx memory usage good - - - based on (and fully compatible with) threads * existing multithreaded programs work @@ -192,6 +181,13 @@ only one at a time will ever run... except no :-) + + +- xxx memory usage good + + + + - transaction.py * demo @@ -219,15 +215,32 @@ . map/reduce, scatter/gather -- Event dispatchers +Event dispatchers +----------------- - * twisted, tulip, etc. +* twisted, tulip, etc. - * run the event dispatcher in one thread (e.g. the main thread), - and schedule the actual events to run on a different thread from - a pool +* run the event dispatcher in one thread (e.g. the main thread), + and schedule the actual events to run on a different thread from + a pool - * the events are run with ``atomic``, so that they appear to run - serially +* the events are run with ``atomic``, so that they appear to run + serially - * does not rely on any change to the user program +* does not rely on any change to the user program + +Donate! +------- + +* STM is primarily funded by donations + +* We got quite far with $22k USD + +* Thanks to the PSF and all others! + +* We need your help too + +Q&A +--- + +* http://pypy.org _______________________________________________ pypy-commit mailing list pypy-commit@python.org http://mail.python.org/mailman/listinfo/pypy-commit