[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