>> "Since we are guaranteeing that synchronized code is running on a single >> core, it is the equivalent of a lock at the cost of a context switch." >> >> This is precisely what a lock costs today: a context switch. >> > > Really? Wouldn't we save some memory allocation overhead (since in my > design, the "lock" is a really just simple kernel instruction as opposed > to a full blown object) The GIL is a single variable, not larger than 50 Bytes or so. Locking it requires no memory at all in user-space, and might require 8 bytes or so per waiting thread in kernel-space. > thereby lowering lock overhead Why do you think "lock overhead" is related to memory consumption? > Since we're using an asynch message queue for the synch-server, it > sounds like a standard lock-free algorithm. You lost me here. What are you trying to achieve? It's not the lock that people complain about, but that Python runs serially most of the time. > I think I neglected to mention that the locking would still need to be > more fine grained - perhaps only do the context switch around refcounts > (and the other places where the GIL is critical). I think this is the point where I need to say "good luck implementing it". > Well, my interpretation of the current problem is that removing the GIL > has not been productive because of problems with lock contention on > multi-core machines. My guess is that this interpretation is wrong. It was reported that there was a slowdown by a factor of 2 in a single-threaded application. That can't be due to lock contention. > If we can somehow guarantee all GC operations (which is why the GIL is > needed in the first place) No, unless we disagree on what a "GC operation" is. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4