Boost logo

Boost :

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.

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