Mike Looijmans
Thu, 26 Jan 2006 22:55:22 -0800
Wow - I wonder how many programs are leaking memory today because ofthis 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