Am 27.10.2016 um 23:49 schrieb Jacob Keller:
Ok, so I've been reading this thread. I don't understand your objections to emulating in this way.. Could you clearly spell out why you believe this solution isn't acceptable? So far all I've understood was "it's not critical sections" and "it penalizes Windows too much" but... If Windows cannot statically initialize a pthread mutex, then we *have* to dynamically initialize it somewhere. This solution adds a single check before each lock and is safe due to use of memory barriers. Yes, this will cost a tiny bit extra overhead for each use of "pthread_mutex_lock" but I fail to see how that is a huge penalty...
One point is that the DCLP idiom must be implemented correctly. There are solutions, of course, and when the initialization is over, we have a miniscule overhead at each pthread_mutex_lock call.
The main point is that the initialization has to solve a chicken-and-egg problem: After we have found an uninitialized critical section, we have to have mutual exclusion for the initialization. We need another critical section for this, but we cannot have one that is initialized. For this reason, the solution uses a different kind of mutual exclusion primitive, which is more akin to POSIX semaphores and works across processes. In the patch proposed by Stefan, a *session-wide* mutex is used. That means that all concurrent git invocations in a user's session synchronize their initialization of critical section objects.
That's just ridiculous. It's like waiting for a ... no, *the* ... battle ship just to get our bouncers in their position. We are talking milliseconds here, not nanoseconds.
-- Hannes