On Saturday, September 21, 2002, at 12:22 PM, Brian wrote:

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

That's a good idea. If you would be willing to contribute suggested changes to the documentation, I'd be happy to edit them and put them in for a coming release.

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.

There are a number of different choices for how to make the reference count thread safe. We would like to have something that is efficient and correct for each platform. Peter Dimov, who wrote shared_count, would presumably be happy to talk to you about alternatives. In addition, the BOOST_NO_THREADS define can be used to request that libraries like the smart pointer library use a non-thread-safe version. This may be practical on a system where threads exist, but the Boost components are used in a way that doesn't require thread safety. In addition, there is a long term goal to create some other smart pointer class template that provides more flexibility about thread safety and other tradeoffs.

BTW, can I submit a VxWorks version of shared_count?

Absolutely. Such contributions are welcome. The page at http://boost.org/more/lib_guide.htm talks about the requirements and guidelines for Boost submissions.

Does boost have an interest in expanding beyond Win32/Posix/Linux?

This is a loaded question. Boost is a collection of libraries that works on many different platforms and is largely platform independent. But each library in Boost is separate. Some libraries that stray beyond what can be done with ISO Standard C++ work only on certain platforms, and many work on only certain compilers because of compiler deficiencies. I think that it would be great to make shared_count thread safe rather than ignoring threading for VxWorks, and perhaps even make Boost.Thread work on VxWorks. -- Darin

From: "Brian"

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.