Re: [boost] [Review] Shmem

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-08 15:13:05

Hi Caleb,

> Please always state in your review, whether you think the library should be
>> accepted as a Boost library!
> An enthusiastic YES.

>> - What is your evaluation of the design?
> The design is very good.

Thanks!

> I agree with others that there should be RAII versions of the constructors
> of various classes like shared_memory and named_shared_object that throw if
> they fail.

You will have them in all classes in the final version.

> Another concern, addressed clearly in the documentation, is the necessity of
> reproducing the synchronization primitives of Boost.Thread and the xtime
> class in Shmem.  This is yet another case where a library that tries to be
> thread-aware, without necessarily being multithreaded itself, has had to do
> this.  From what I can gather from some grepping,
> Boost.Pool(pool/detail/mutex.hpp) and
> Boost.Regex (regex/pending/static_mutex.hpp) contains their own mutex
> implementation as well.  Also, the proposed Logging library (which was
> pulled before the review was complete) and ASIO both contain some elemental
> synchronization classes that could be a more fundamental part of Boost.
> 
> I think it is high time for the separation of the synchronization primitives
> of Boost.Thread into a separate library before they are duplicated again.
> This duplication has the follow-on issues of reduced portability for the
> library that reproduces them and the possibility of bugs being introduced.

I agree. The problem is that Boost Thread seems to be in stand-by mode, 
so I don't know if we will have any chance to change the situation.

> I'm also intrigued by the reproduction of many Standard Library containers
> due to implementation restrictions (under Current Limitations, "Problems
> with most STL implementations").  Ion, can you include a listing of
> platforms for which the Shmem versions of containers must be used and ones
> where the Standard Library containers can be used with the Shmem allocator?

As far as I know there is no single platform that supports Shmem/smart 
pointer allocators. Dinkumware STL was close, though. SGI-derived ones 
(stlport, libstdc++) use raw pointers so they are also incompatible. I 
don't know about Metrowerks and RogueWave-Apache, maybe Metrowerks won't 
be far.

> Are there any of the latter?  A table would be quite useful here.  For
> compilers with a reasonable hope of getting changes fed into the Standard
> Library implementation (e.g. gcc) it might be worthwhile to contact the
> maintainers about these limitations to see if they can be removed.

I have already commented this with Howard Hinnant and Paolo Carlini from 
  libstdc++ in a private mail. They want to support shared memory 
allocators but the work is not trivial, since raw pointers are 
everywhere. I'm ready to help them.

>>From Current Limitations / "Be careful with static class members":
> 
> "Static members are not dangerous if they are just constant variables
> initialized when the process starts, but they don't change at all (for
> example, when used like enums)."
> 
> I'm not sure I understand the second half of this sentence.  What does it
> mean to use a static variable like an enum?  Maybe I'm just being
> thick-headed.

I just wanted to say that if you have "static const int a = 5"  (like 
enum { a = 5 };) declarations that are just constant integral values, 
there is no harm. Each process will read their own copy and since both 
will be the same (supposing they use the same version of the class, of 
course) there is no problem.

> The Introduction states:
> 
> "Shmem also offers the basic_string pseudo-container to use full-powered C++
> strings in shared memory."
> 
> But this class isn't documented.  I see it in the header
> <boost/shmem/containers/string.hpp>.  Actually it appears that none of the
> headers in the shmem/containers dir are mentioned explicitly in the
> documentation.  They are touched on briefly in "Shmem and containers in
> shared memory", but this documentation might benefit from some expansion.

Sorry about containers. They are not documented at all, since all are 
standard C++ containers in boost::shmem namespace. The only new 
container family is the Loki AssocVector derived flat_map family. I 
agree that I should document that at least. I don't know if 
documentation for others is needed since they are standard C++ 
containers in boost::shmem namespace. But if this is what boosters want, 
I will document them (but it's quite a hard work).

> - What is your evaluation of the potential usefulness of the library?
> 
> 
> I think it has great potential, especially if the memory segments can be
> made to grow (fingers crossed!).

I will try to write a small paper about multi-segment shared memory 
architecture (I mean allocating new segments when we need more memory) 
and the problems I've found when trying to construct them. But this will 
be after Shmem review ends (and if it's accepted, after I make the 
requested changes).

> - Did you try to use the library? With what compiler? Did you have any
>> problems?
> 
> I didn't actually use the library other than to compile and run the tests
> w/gcc 3.3.4 on Linux.  I did run into one error trying to compile the tests
> with a CVS version of Boost from this morning:

I don't have access to gcc 3.3.4 right now but I will try to discover 
what's going wrong. If you can find any solution, please let me know.

Thanks for your review!

Ion