[pypy-commit] extradoc extradoc: additions

[Raemi]

Author: Remi Meier <remi.meier at inf.ethz.ch>
Branch: extradoc
Changeset: r5212:884401952998
Date: 2014-05-02 09:39 +0200
http://bitbucket.org/pypy/extradoc/changeset/884401952998/

Log:	additions

diff --git a/talk/icooolps2014/position-paper.tex b/talk/icooolps2014/position-paper.tex
--- a/talk/icooolps2014/position-paper.tex
+++ b/talk/icooolps2014/position-paper.tex
@@ -206,7 +206,12 @@
 access the same objects in parallel. What we lose instead is the
 simplicity of the GIL approach. With every additional lock, the
 likeliness of deadlocks grows, as well as the overhead that acquiring
-and releasing locks produces.
+and releasing locks produces. The former means that sometimes it is
+necessary to fall back to less fine-grained locking, preventing some
+potential parallelism in order to keep the complexity manageable.
+The latter means that we lose a bit of performance in the
+single-threaded case compared to the GIL, which requires much less
+acquire-release operations.
 
 Jython\footnote{www.jython.org} is one project that implements an
 interpreter for Python on the JVM\footnote{Java Virtual Machine} and
@@ -215,7 +220,7 @@
 carefully placed locks. Since there is no central location, the
 complexity of the implementation is quite a bit greater compared to
 using a GIL. Integrating external, non-thread-safe libraries should
-however be very simple too.  One could simply use one lock per library
+however be very simple too. One could simply use one lock per library
 to avoid this issue.
 
 In the end, fine-grained locking can transparently replace the GIL
@@ -230,7 +235,7 @@
 %% - (there are some semantic differences, right? not given perfect lock-placement, but well)
 %% ( http://www.jython.org/jythonbook/en/1.0/Concurrency.html )
 
-\subsubsection{Shared-Nothing / multiple processes}
+\subsubsection{Shared-Nothing}
 
 There are also approaches that work around the GIL instead of trying
 to replace it. If an application can be split into completely