Gennaro Prota wrote:
On Sun, 06 Aug 2006 21:03:14 +0200, Ion Gaztañaga <igaztanaga@gmail.com> 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.