I recommend that Shmem be accepted into Boost. Most of my comments below have already been raised by other posters, so I'll just mention which I agree with. I would use Shmem today if it were available in its final form in Boost. - What is your evaluation of the design? I was impressed with the breadth and depth of the design. It thoroughly covers this domain. My only suggestion for the design would be to separate the concept of mmapped_file from that of the mapped region. The mmapped_file class should just be concerned with managing the "backing store", whether that is an ordinary file, /dev/zero, or the Windows swap file. The mmapped_region is responsible for mapping a portion (or all) of the mmapped_file into the process's memory space, and you could have multiple mmapped_regions per mmapped_file. The current implementation could be covered with a convenience class/factory that creates a mmapped_region that maps an entire mmapped_file. - What is your evaluation of the implementation? Overall, quite impressed. I am in strong agreement with the "RAII crowd" in that I do not want to see two phase initialization. To summarize which of the sub-arguments I agree with, or find to be important: 1. I would like to see constructors that throw when they cannot construct the object. 2. I see no compelling need for fstream() equivalent "empty" constructors 3. I do agree that "reopen()" is a useful concept, and that it could also throw. 4. For embedded environments that cannot use exceptions, I suggest using boost::config to disable the throwing() behavior, and provide an "isValid/isOpen" accessor function which would allow embedded developers to interrogate the state of the object. When exceptions are turned on, this function would always return true. Re: Boost::Threads and synchronization primitives I agree that Shmem provides (yet another) compelling case for factoring Boost::Threads into synchronization primitives and higher level thread management objects (threads, pools, thread specific storage, etc.). The synchronization primitives are too useful as separate objects. - What is your evaluation of the documentation? I actually thought it was adequate, if a little rough around the edges. I'm familiar with the problem domain, though. - What is your evaluation of the potential usefulness of the library? Having a comprehensive, cross-platform library for shared memory is hugely useful. - Did you try to use the library? With what compiler? Did you have any problems? I evaluated this library using VC 7.1 and VC 8.0 without problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I put a moderate amount of effort into this evaluation. I read the documentation and looked in depth at the file mapping and allocator objects. - Are you knowledgeable about the problem domain? Yes, I've used shared memory objects and synchronization extensively in financial and research application development. Regards, Dave Moore