You are right, there is no lightweight mutex for Carbon since nobody submitted one. :-)
In Boost 1.29 and earlier, the #error was commented out, and shared_ptr silently fell back to the non-thread safe implementation.
If you don't need a thread safe shared_ptr, you can replace the #error with
# include <boost/detail/lwm_nop.hpp>
If you need the thread safety, and you are familiar with Carbon MP tasks, you can write a lightweight mutex implementation for this platform and submit it for inclusion. Or you can simply typedef boost::mutex as boost::detail::lightweight_mutex, if you don't mind linking with Boost.Threads.
HTH
That helps tremendously. I do have a couple questions though. 1. How non-thread-safe is the non-thread-safe implementation? As long as a shared_ptr is only used in one thread am I ok? Or is there issues even there if I am creating shared ptrs in more than one thread? (Like are they sharing some kind of custom allocator?) Just curious what guaruntees there are there (if any) without the mutex. 2. I may consider writing an implementation for Mac. As far as I know there is not any sort of mutex in the MP library that is faster and lighter weight than the MP critical section stuff which I am sure boost::mutex uses - but it would be extrordinarily helpful for me if there was a header-only mutex implementation for the shared_ptr to use on Mac so I don't have to link Boost threads into all of my projects. I have a central library that uses shared_ptr heavily, and it also contains some thread code. A lot of projects share that library, but I only link the thread stuff in if I actually use the thread-dependent parts of the library. If I were to write one who would I give it to to consider for inclusion? -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------