Re: [PATCH] MSVC: port pthread code to native Windows threads

> On Wed, 4 Nov 2009, Nicolas Pitre wrote:
> 
> > On Wed, 4 Nov 2009, Daniel Barkalow wrote:
> > 
> > > On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> > > 
> > > > 2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
> > > > >
> > > > > You are right. But #ifdef THREADED_DELTA_SEARCH is about a "generic"
> > > > > property of the code and is already used elsewhere in the file, whereas
> > > > > #ifdef WIN32 would be new and is is about platform differences.
> > > > >
> > > > > Anyway, we would have to see what Junio says about the new function calls,
> > > > > because he's usually quite anal when it comes to added code vs. static
> > > > > initialization. ;)
> > > > 
> > > > I could do it with wrappers for pthread_mutex_lock and _unlock and
> > > > lazy init there plus lazy init cond var in cond_wait and _signal, that
> > > > way it could be done without any additional code in the first #ifdef.
> > > > But I don't see any simple solution for working around
> > > > deinitialization, that's why I'd leave non-static initialization. Let
> > > > me put some touchups and resubmit for another round.
> > > 
> > > Is it actually necessary to deinitialize? Since the variables are static 
> > > and therefore can't leak, and would presumably not need to be 
> > > reinitialized differently if they were used again, I think they should be 
> > > able to just stay. If Windows is unhappy about processes still having 
> > > locks initialized at exit, I suppose we could go through and destroy all 
> > > our mutexes and conds at cleanup time. Pthreads does have the appropriate 
> > > functions, and it would be correct to use them, although unnecessary.
> > 
> > Lazy initialization would probably turn up to be more expensive 
> > (checking a flag on each usage) than unconditionally initializing them 
> > once.  Remember that those are used at least once per object meaning a 
> > lot.
> 
> Meh, checking a flag on the same cache line as the lock you're about to 
> take can't be a big incremental cost, especially if it's actually checking 
> whether some sort of cookie is non-zero before doing something with it.