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

On Thu, Oct 27, 2016 at 10:55 PM, Johannes Sixt [off-list ref] wrote:

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.

Right, this I understood, but appeared to be solved.

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.

Thank you for explaining this. Now I understand why this would be
considered a big issue, and potentially worth considering the
alternatives like attr_start. This was missing since I don't think any
of the rest of us knew (correct me if I am wrong) that the
synchronization would be global. For many cases it's probably not that
bad, but we do have a suitable explanation, and I think living with
"attr_start()" in the win32 initialization path which is something
Stefan suggested in a previous email would make the most sense then.

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.

Right. Thanks for filling in the missing details.

Regards,
Jake

-- Hannes