Wow - I wonder how many programs are leaking memory today because of
this double-check issue. I've been using it myself for years (yes, also
in Java)...
Having read the article, I've come to the following conclusions:
- Python indeed won't suffer from this problem. But I agree to keep on
the safe side, the optimization is not worth the problems it might cause
later.
- I'll never use it again. (Unless I'm hacking away in assembly and have
to write my own locking and threading code anyway...)
--
Mike Looijmans
Philips Natlab / Topic Automation
Nicolas Lehuen wrote:
Your optimisation is called "double-checked locking", and it is now
known to be broken, especially on multiple-CPU systems. The problem
exists in numerous languages. Here is an explanation of the problem :
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Now, maybe Python is not touched by this problem due to its relatively
poor support for multithreading. The presence of the GIL guarantees
that only one thread of Python bytecode interpreter runs at a time,
but still, in a multiple CPU environment, you can get bitten by local
caching issues.
As this thing is a bit hairy, I think we should first strive for
correctness, then care about performance later. And no, I won't bother
you with one more quote about premature this and the root of that ;).
Regards,
Nicolas
--
Mike Looijmans
Philips Natlab / Topic Automation
