Re: [boost] [interprocess] New snapshot and some explanations

From: Edward Diener (eddielee_at_[hidden])
Date: 2006-08-08 20:32:42

Gennaro Prota wrote:
> On Sun, 06 Aug 2006 21:03:14 +0200, Ion Gaztañaga
> <igaztanaga_at_[hidden]> wrote:
> 
>>> Since there are already synchronization primitives in Boost.Thread and 
>>> in numerous other Boost libraries which roll their own, would it not be 
>>> efficacious for Boost to develop a separate synchronization primitive 
>>> library which then could be used by all other Boost libraries.
>> Well, Boost.Thread and Boost.Interprocess aren't the libraries where 
>> this synchronization should go?
> 
> I think Edward was just proposing more coordination between library
> authors. I second that. Many times useful components are buried down
> into a detail/ subdirectory somewhere, waiting for someone to refine
> them and bring them to light. That usually never happens. When I come
> upon similar situations (components which might be useful on their
> own) I try to put them in the pending/ subdirectory, which at least
> makes them a bit more visible; but in fact that has not proven to be a
> solution.

I was generally proposing that low-level synchronization primitives are 
a useful concept of their own which could be used by many other Boost 
libraries, and therefore should be their own Boost library. Obviously a 
synchronous primitives library could be used in any situation where 
asynchronous access to data is required.

Of course synchronization primitives, by which I mean, for example, such 
well-known concepts such as mutexes, semaphores, events, locking 
mechanisms, atomic operations, and shared memory, are highly dependent 
on the operating system and therefore a good low-level synchronization 
primitive library, implementing most or all of the concepts above, must 
have knowledge of how each operating systems implement these concepts. I 
am aware of the shmem library, for shared memory, already although I 
have not used it yet. But all, or nearly all of the concepts above could 
benefit from a cross-platform Boost libary.

My idea of such a library is strictly low-level and the common 
denominator idea. Then other Boost libraries, which use one or more of 
the implementations for any of the concepts mentioned, would be free, if 
necessary, to build on the low-level synchronization primitive's 
implementation without having to worry about cross-platform programming 
of their own more complicated needs.