Author: Remi Meier <remi.me...@inf.ethz.ch>
Branch: extradoc
Changeset: r5234:18ba53e1a5b4
Date: 2014-05-05 13:54 +0200
http://bitbucket.org/pypy/extradoc/changeset/18ba53e1a5b4/
Log: another comment
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
@@ -274,14 +274,15 @@
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
-and therefore parallelise existing applications, generally without any
+In the end, fine-grained locking can transparently replace the GIL and
+therefore parallelise existing applications, generally without any
changes\footnote{There are rare cases where not having atomic
-bytecodes actually changes the semantics.}
-It does however not provide a better synchronisation
-mechanism to the application like e.g. atomic blocks.
+ bytecodes actually changes the semantics.}. An implementation has to
+follow the GIL semantics very closely, otherwise it may expose some
+latent data races in existing applications which are just not exposed
+with a GIL. This approach does however not provide a better parallelising
+synchronisation mechanism to the application like e.g. atomic blocks.
-\cfbolz{I think you should mention the commented out point below, that a lot
of existing code contains latent races / deadlocks that are just not exposed in
a GIL-full world}
%% - support of atomic blocks?\\
%% - hard to get right (deadlocks, performance, lock-granularity)\\
%% - very hard to get right for a large language\\
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit
