Probably I want to re-invent a bicycle. I want developers to say me why we can not remove GIL in that way: 1. Remove GIL completely with all current logick. 2. Add it's own RW-locking to all mutable objects (like list or dict) 3. Add RW-locks to every context instance 4. use RW-locks when accessing members of object instances Only one reason, I see, not do that -- is performance of singlethreaded applications. Why not to fix locking functions for this 4 cases to stubs when only one thread present? For atomicity, locks may be implemented as this: For example for this source: -------------------------------- import threading def x(): i=1000 while i: i-- a = threading.Thread(target=x) b = threading.Thread(target=x) a.start() b.start() a.join() b.join() -------------------------------- in my case it will be fully parallel, as common object is not locked much (only global context when a.xxxx = yyyy executed). I think, performance of such code will be higher that using GIL. Other significant reason of not using my case, as I think, is a plenty of atomic processor instructions in each thread, which affect kernel performance. Also, I know about incompatibility my variant with existing code. In a summary: Please say clearly why, actually, my variant is not still implemented. Thanks. -- Segmentation fault
Марк Коренберг, 09.08.2011 11:31:
In a summary: Please say clearly why, actually, my variant is not still implemented.
This question comes up on the different Python lists every once in a while. In general, if you want something to be implemented in a specific way, feel free to provide the implementation. There were several attempts to remove the GIL from the interpreter, you can look them up in the archives of this mailing list. They all failed to provide competitive performance, especially for the single-threaded case, and were therefore deemed inappropriate "solutions" to the "problem". Note that I put "problem" into quotes, simply because it is controversial if the GIL actually *is* a problem. This question has also been discussed and rediscussed in great length on the different Python lists. Stefan
participants (2)
-
Stefan Behnel
-
Марк Коренберг