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

Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-10-30 05:37:26

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).

> 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.

Which are your requirements? If you plan to build portable 
synchronization objects for intra-process, I think that for intraprocess 
the natural library is to propose them for Boost.Thread. If you plan to 
build inter-process mechanisms, then it should fit Interprocess 
requirements.

> 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.

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

Best,

Ion