Boost logo

Boost :

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

> 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



Boost list run by bdawes at, gregod at, cpdaniel at, john at