Boost logo

Boost :

Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-10-29 08:06:29

El 29/10/2011 12:42, Dan Brown escribió:

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


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