[pypy-commit] extradoc extradoc: Abstract for the STM talk.

arigo noreply at buildbot.pypy.org
Tue Mar 20 18:13:59 CET 2012


Author: Armin Rigo <arigo at tunes.org>
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.


More information about the pypy-commit mailing list