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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Oct 28, 2016, 06:11 UTC
Message-ID: <CA+P7+xrvHfTd77uTM+g1_QyWFvQuak2x-wdej7hD99v-37AOLg@mail.gmail.com>
In-Reply-To: <2ddca5e3-3c4d-b555-4309-a180ceed581e@kdbg.org>

On Thu, Oct 27, 2016 at 10:55 PM, Johannes Sixt <j6t@kdbg.org> 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.

Show 10 quoted lines

> 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
>