Macintosh Carbon Thread Error with Boost 1.30.0
Hey guys, I just tried to get the new Boost 1.30.0 release to work on MacOS, using TARGET_CARBON (with threads turned on). I have a problem to report: there's a new "lightweight mutex" being used by the smart pointer library. There does not seem to be a lightweight mutex implementation for the "Carbon MP tasks" thread implementation. So - when I compile my code under Boost 1.30 I end up at: # error Unrecognized threading platform in lightweight_mutex.hpp when it tries to compile any of the smart pointer stuff. Help! :-) -- Bobby --------------------------------------------------------------------- Bobby Thomale Senior Software Developer Inoveon Corporation http://www.inoveon.com/ ---------------------------------------------------------------------
Bobby Thomale wrote:
Hey guys,
I just tried to get the new Boost 1.30.0 release to work on MacOS, using TARGET_CARBON (with threads turned on).
I have a problem to report: there's a new "lightweight mutex" being used by the smart pointer library.
There does not seem to be a lightweight mutex implementation for the "Carbon MP tasks" thread implementation.
So - when I compile my code under Boost 1.30 I end up at:
# error Unrecognized threading platform
in lightweight_mutex.hpp when it tries to compile any of the smart pointer stuff.
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
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/ ---------------------------------------------------------------------
Bobby Thomale wrote:
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.
If you don't pass a shared_ptr across threads you should be fine without the mutex. By default, shared_ptr doesn't use a custom allocator.
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?
Just post it here, or to the developer's list.
participants (1)
-
Bobby Thomale -
Peter Dimov