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