Re: [Boost-Users] shared_ptr documentation suggestion

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-22 09:55:24

From: "Brian" <bneal_at_[hidden]>
> I started to look at shared_ptr for my needs (working in a realtime
> embedded systems environment). I started wondering how it protects
> its reference count but was surprised to not see anything about this
> in the documentation. Examining the code I see it uses a platform
> specific mutex type mechanism if it is available. Otherwise the
> reference count is not thread safe. I was also alarmed to see that
> the #error "your reference count is not thread safe" was commented
> out!

Yes. This was a (probably misguided) attempt to limit incompatibilities
between 1.26 and 1.27, as shared_ptr in 1.26 was never thread safe.

Also, shared_ptr relies on the macros set by Boost.Config to detect whether
a platform supports threads. If BOOST_HAS_THREADS is not defined on your
platform, you'll always get the non-thread-safe version.

> Just a suggestion: mention in the documentation whats going on here.

Will do. The threading primitives used by shared_ptr were originally
supposed to be a stopgap solution until Boost.Threads officially Takes Over
the World, but for various reasons this didn't happen, and it's probably
time to document "what's going on here." :-)

> The operating system I am using (VxWorks) is not supported by
> shared_count right now, and had I not been curious I would have not
> noticed this. Also, even if it was, it can be very expensive for a
> realtime embedded system (e.g. running on a very slow processor) to
> take a mutex, especially if done at a very high rate, which is a
> concern of mine in a few places in my code.
>
> BTW, can I submit a VxWorks version of shared_count? Does boost have
> an interest in expanding beyond Win32/Posix/Linux?

Yes. Platform-specific implementations of detail::atomic_count (used by
1.27) and detail::lightweight_mutex (used by the later versions) are
welcome. Please take the time to read the comments in (the latest versions
of) atomic_count.hpp and lightweight_mutex.hpp, though, as writing optimized
threading primitives by hand is very difficult and error prone, as I learned
the hard way. Of course a realtime OS should already have such primitives;
I'm not familiar with VxWorks.

You should also ensure that Boost.Config correctly detects the features of
your platform; see the output of config_test.cpp and config_info.cpp.