> No: fairness in mutex synchronization means that every waiter for the > mutex will eventually acquire it; it won't happen that one thread > starves waiting for the mutex. This is something that the mutex needs to > provide, not the application.
Right, I guess I was thinking of it in terms of needing to release the mutex at some point in order for it to be later acquired. > Please trust Antoine that it's relevant: if the current implementation > isn't fair on Linux, there is no need for the new implementation to be > fair on Windows. Fair enough. -- While setting up my patch, I'm noticing something that could be potentially bad for this idea that I overlooked until just now. I'm going to hold off on submitting a ticket unless others suggest it's a better idea to keep this discussion going there. The thread module's lock object uses the same code used to lock and unlock the GIL. By replacing the current locking mechanism with a critical section, it'd be breaking the expected functionality of the lock object, specifically two cases: 1. Blocking recursion: Critical sections don't block on recursion, no way to enforce that 2. Releasing: Currently any thread can release a lock, but only the owner release a critical section Of course blocking recursion is only meaningful with the current behavior of #2, otherwise it's an unrecoverable deadlock. There are a few solutions to this. The first would be to implement only the GIL as a critical section. The problem then is the need to change all of the core code that does not use PyEval_Acquire/ReleaseLock (there is some, right?), which is the best place to use something other than the thread module's locking mechanism on the GIL. This is doable with some effort, but clearly not an option if there is any possibility that extensions are using something other than the PyThreadState_*, PyGILState_* and PyEval_* APIs to manipulate the GIL (are there others?). After any of this, of course, I wonder what kind of crazy things might be expected of the GIL externally that requires its behavior to remain as it is. The second solution would be to use semaphores. I can't say yet if it would be worth it performance-wise so I will refrain from conjecture for the moment. I like the first solution above... I don't know why non-recursion would be necessary for the GIL; clearly it would be a little more involved, but if I can demonstrate the performance gain maybe it's worth my time. - Phillip _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
