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 19:48:05

> > 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?
> 
> Interprocess tries to be portable and that means choosing a model for
> lifetime, etc. The chosen model is POSIX. Windows has essentially
> *named* process synchronization mechanisms, but their lifetime semantics
> are radically different than POSIX ones, and that's a problem (although
> solvable, as I think cygwin manages this). Several emulation layers need
> services, daemons, etc, a model Interprocess and Boost don't follow.
> 
> ACE does not support mutexes placed in shared memory
> (_POSIX_THREAD_PROCESS_SHARED). Cygwin does not support it. APR does
> not support it.

This was actually my intended point, though maybe I didn't make it clearly.  The fact that these libraries (ACE, etc.) provide intraprocess sync objects but not interprocess sync objects is evidence that intraprocess sync objects meet many people's needs.  In fact, I find that I need sync objects within a process much more often than I need them between processes.

If the boost.interprocess sync usage model cannot be more efficiently implemented on win32, either by finding a way to implement the current model, by relaxing the model's requirements (see my next question below), or by providing strictly intraprocess versions of sync objects, then they're unsuitable for my current purposes.  I don't think my requirements are unusual in this respect either.  Based on my own needs and the fact that other libraries like ACE provide this cross-platform functionality convinces me that Boost would benefit from the addition of similar intraprocess sync objects.

> I've reviewed several libraries to find a better solution than
> current spinlock-based code, but still have not found a good solution. I'm not
> saying that it does not exists, I'm just saying that it is not as simple as it might
> seem. Interprocess has a solution, not very efficient but portable.

To this point in the discussion, only issue I can see as fundamentally preventing the proposed implementation from working (assuming the addition of named-event fixes I alluded to earlier) is the named-object "lifetime semantics" issue that you mentioned, but I'm not sure I understand it fully.  It would be helpful for me if you could you clarify the difference in sync object lifetime semantics that make cross-process named win32 sync objects unsuitable for supporting the boost.interprocess version of pthread sync object semantics.