Re: [boost] [interprocess] native Windows cond_var + mutex

Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
From: Dan Brown (dbrown_at_[hidden])
Date: 2011-10-29 06:42:31

> > Yes and no.  You're correct in that I overlooked the use of handles
> > for interprocess_condition.  I believe, though, that solving this for
> > the interprocess_condition event handles is the same as the solution I
> > use for win32/interprocess_mutex.  Named mutexes (and events) can be
> > used cross-process.  It's a fairly straightforward fix unless I'm
> > missing something.  I'll get you an updated patch shortly.
> 
> For each lock you are creating handles without closing them (leaks) and

Yes, lock() and wait() have this leak.  I will address this in a new patch.

> connecting by name for each lock is also pretty inefficient. 

Agreed.  However, the trade is substantially reduced latency, since currently, waking on signaled sync objects on win32 require at least an average of a half ms.

> CloseHandle in the
> destructor is useless, as no one is going to call it as users will just remove
> shared memory.

I'm not sure I understand this point and perhaps I don't understand the intended usage model for interprocess mutex/condvar well enough.  Do you mean that an expected valid use of sync objects is to construct them in shared memory but not destroy them - only delete their underlying storage?  Is this explicit or implicit in sync object documentation?  Or am I misunderstanding your point?

> Mutex names are local and can't be seen by other
> users/services....

Wouldn't appending "Global\" to the win32 synchronization objects address this scoping issue?

> Believe me, using native calls to emulate process-shared pthreads is not that
> easy.

I'm open to that possibility but I'm still not convinced that this solution is as fundamentally off the mark as you seem to be suggesting.  I will try to provide a new patch soon that addresses at least some of the issues you've raised to support that position.  In my mind this also re-raises the question of whether strictly intraprocess synchronization objects could be useful, since these are, if not more common than strictly inter-process sync objects, at least very commonly used on Windows and I believe other platforms as well (ACE provides these for example).  This is, in fact, precisely what I was hoping to use interprocess for in my own cross-platform project.  But perhaps a library called "interprocess" is not the right home for these?