Author: Armin Rigo <[email protected]> Branch: extradoc Changeset: r4156:2998cba304fd Date: 2012-03-20 18:13 +0100 http://bitbucket.org/pypy/extradoc/changeset/2998cba304fd/
Log: Abstract for the STM talk. diff --git a/talk/ep2012/stm/abstract.rst b/talk/ep2012/stm/abstract.rst new file mode 100644 --- /dev/null +++ b/talk/ep2012/stm/abstract.rst @@ -0,0 +1,27 @@ + +Kill the GIL..? +=============== + +The GIL, or Global Interpreter Lock, is a well-known issue for Python +programmers that want to have a single program using the multiple cores +of today's machines. + +This talk is *not* about writing a GIL-less Python interpreter; although +hard, this has been done before, notably in Jython. The real issue is +that writing each and every multi-threaded Python programs is hard too. +The ``threading`` module offers locks in several variants, conditions, +events, semaphores... But using them correctly without missing one case +is difficult, impossible to seriously test, often impossible to retrofit +into existing programs, and arguably doesn't scale. (Other solutions +like the ``multiprocessing`` module are at best workarounds, suffering +some of the same issues plus their own ones.) + +Instead, this talk is about an alternate solution: a minimal thread-less +API that lets programs use multiple cores, without worrying about races. +This may sound impossible, but is in fact similar to the API +simplification of using a garbage collected language over an explicitly +managed one --- what is not minimal is "just" the internal +implementation of that API. I will explain how it can actually be done +using Automatic Mutual Exclusion, a technique based on Transactional +Memory. I will give preliminary results on a modified version of the +PyPy Python interpreter that show that it can actually work. _______________________________________________ pypy-commit mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-commit
