Re: [PATCH] compat: Allow static initializer for pthreads on Windows

From: Johannes Sixt <j6t@kdbg.org>
Date: Oct 28, 2016, 05:55 UTC
Message-ID: <2ddca5e3-3c4d-b555-4309-a180ceed581e@kdbg.org>
In-Reply-To: <CA+P7+xpckfaeHmoEGQBdLD-=Kf7gQ-jOxGFKrKmiFH1SBN7GjA@mail.gmail.com>

Am 27.10.2016 um 23:49 schrieb Jacob Keller:

Show 10 quoted lines

> 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