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-30 10:34:46

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-
> bounces_at_[hidden]] On Behalf Of Ion Gaztañaga
> Sent: Sunday, October 30, 2011 5:37 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
> 
> El 30/10/2011 1:48, Dan Brown escribió:
> 
> > 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.
> 
> Interprocess is about cross-process, if you need intra-process Boost.Thread is
> the natural way. In Interprocess you can customize mutexes used by some
> classes for intra-process via templates (see
> http://www.boost.org/libs/dic/html/interprocess/customizing_interprocess.
> html
> and class reference for details).

The fact that Boost.Thread provides sync objects is an embarrassing oversight on my part and solves my immediate problem.  Thanks for the pointer.  Continued curiosity below...

> It's a bit long to explain but in windows named resources are reference-
> counted and are destroyed when the last attached process dies/detaches.
> Windows has no unnamed process-shared synchronization primitives,
> unnamed ones are intra-proces only.
> 
> In POSIX named resources are file-like (they live until they are explicitly
> removed) and unnamed can be intra-process or interprocess
> (PTHREAD_PSHARED). Unnamed interprocess resources must be
> constructed in shared memory/memory mapped files, use them, unmap
> them, remap them and continue usihng them. For more details I
> recommend:
> 
> UNIX Network Programming, Volume 2, Second Edition: Interprocess
> Communications
> 
> http://www.kohala.com/start/unpv22e/unpv22e.html

Thanks for the explanation.  The mutex implementation I provided intends to provide "unnamed-like" cross-process mutex semantics by assigning random names.  The same can be done with the internal events in interprocess_condition to make them properly interprocess.  I realize this presents the corner case of name collision with user-named objects, but this seems unlikely enough not to be a major consideration.

Now that I understand the lifetime that applies to (file-like) named objects issue a little better I'm still unsure of why it matters.  Why does it matter (other than performance) if on Windows, the object happens to be deleted when the last reference goes away?  The "explicit destroy" operation is then a noop on Windows.  When it is referenced again it is recreated.  There must be some use case that is not occurring to me right now.

This is a little bit academic for me now but I remain curious about this case.  If a mutex is destroyed in the forest and no one is around to lock it, does it make a sound?  ;-)