Hi, I've been continuing my quest to try and use Boost for my DSP and its C++ compiler. I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source. Is this an issue that has been raised before? Thanks Andrew
On Dec 20, 2007, at 9:38 AM, Eames, Andrew wrote:
Hi,
I've been continuing my quest to try and use Boost for my DSP and its C++ compiler. I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source. Is this an issue that has been raised before?
There is an ongoing effort to standardize a variation of the boost threads lib, most recently documented here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm Part of the motivation for the departure from the boost::threads API is to allow client-defined mutexes work with std::defined locks and condition variables. Anthony Williams has been updating the boost::threads lib on the boost main svn trunk, taking into account the standards work. This paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html has a good rationale for the current mutex/lock and condition variable design, though a few of the names have changed since this paper was written. The opening paragraph for the Mutex Rationale in this paper is:
The overall intent of the above design is to allow user defined mutexes to work with standard defined locks, and to also allow standard defined mutexes to work with user defined locks. The standard defined mutexes and locks create mutex and lock concepts, which if followed allow for the interoperability between user defined and standard defined components (much like our existing containers and algorithms interoperate with user defined containers and algorithms).
-Howard
Very interesting - thanks for the links Andrew -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Howard Hinnant Sent: Thursday, December 20, 2007 4:06 PM To: boost@lists.boost.org Subject: Re: [boost] Boost.Thread and extensibility On Dec 20, 2007, at 9:38 AM, Eames, Andrew wrote:
Hi,
I've been continuing my quest to try and use Boost for my DSP and its C++ compiler. I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source. Is this an issue that has been raised before?
There is an ongoing effort to standardize a variation of the boost threads lib, most recently documented here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm Part of the motivation for the departure from the boost::threads API is to allow client-defined mutexes work with std::defined locks and condition variables. Anthony Williams has been updating the boost::threads lib on the boost main svn trunk, taking into account the standards work. This paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html has a good rationale for the current mutex/lock and condition variable design, though a few of the names have changed since this paper was written. The opening paragraph for the Mutex Rationale in this paper is:
The overall intent of the above design is to allow user defined mutexes to work with standard defined locks, and to also allow standard defined mutexes to work with user defined locks. The standard defined mutexes and locks create mutex and lock concepts, which if followed allow for the interoperability between user defined and standard defined components (much like our existing containers and algorithms interoperate with user defined containers and algorithms).
-Howard _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 10432610) is spam: Spam: http://mail-gw.cognex.com/canit/b.php?c=s&i=10432610&m=ed2120cdd19e Not spam: http://mail-gw.cognex.com/canit/b.php?c=n&i=10432610&m=ed2120cdd19e Forget vote: http://mail-gw.cognex.com/canit/b.php?c=f&i=10432610&m=ed2120cdd19e ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
Eames, Andrew wrote:
I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source.
Hi Andrew, I have also written a few of my own mutex and thread classes. What sort of integration do you want between your mutexes (etc) and the Boost code? Some of the things that occurred to me were: - Make boost::mutex (etc) actually use your code on your platform; I think this requires that you augment the Boost code with an additional set of #if blocks. You might prefer to just write your own classes with interfaces compatible with the Boost ones and select them by means of "using namespace". - Make your classes inter-operate with the Boost classes (e.g. using your mutex with the Boost lock or condition class); this is more possible with the newer Boost and proposed std:: classes, but you'll find some issues e.g. std::condition_var_any looks as if it can work with a mutex that you provide, but actually it still relies on its own default mutex (e.g. POSIX) being available internally. - Make your classes inter-operate with thread cancellation / interruption. This is only an issue if you have any sort of cancellation in the first place, of course.... - Make other bits of Boost use your classes (e.g. the shared_ptr atomic reference count). I think that this also requires that you add a set of #if blocks in each case. Is there anything else that you have in mind? Phil.
Thanks for the suggestions - I already have my mutex classes. I was just looking to throw them away and use something more off the shelf. It looks like this is on the way so I think I'll just be patient and wait! Andrew -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Endecott Sent: Thursday, December 20, 2007 7:15 PM To: boost@lists.boost.org Subject: Re: [boost] Boost.Thread and extensibility Eames, Andrew wrote:
I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source.
Hi Andrew, I have also written a few of my own mutex and thread classes. What sort of integration do you want between your mutexes (etc) and the Boost code? Some of the things that occurred to me were: - Make boost::mutex (etc) actually use your code on your platform; I think this requires that you augment the Boost code with an additional set of #if blocks. You might prefer to just write your own classes with interfaces compatible with the Boost ones and select them by means of "using namespace". - Make your classes inter-operate with the Boost classes (e.g. using your mutex with the Boost lock or condition class); this is more possible with the newer Boost and proposed std:: classes, but you'll find some issues e.g. std::condition_var_any looks as if it can work with a mutex that you provide, but actually it still relies on its own default mutex (e.g. POSIX) being available internally. - Make your classes inter-operate with thread cancellation / interruption. This is only an issue if you have any sort of cancellation in the first place, of course.... - Make other bits of Boost use your classes (e.g. the shared_ptr atomic reference count). I think that this also requires that you add a set of #if blocks in each case. Is there anything else that you have in mind? Phil. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 10434284) is spam: Spam: http://mail-gw.cognex.com/canit/b.php?c=s&i=10434284&m=28ad193869cd Not spam: http://mail-gw.cognex.com/canit/b.php?c=n&i=10434284&m=28ad193869cd Forget vote: http://mail-gw.cognex.com/canit/b.php?c=f&i=10434284&m=28ad193869cd ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS
Eames, Andrew <andrew <at> cognex.com> writes:
I've been continuing my quest to try and use Boost for my DSP and its C++ compiler. I've been looking at Boost.Thread and it seems that it relies on one of a fixed few threading libraries to exist. I have my own native implementation of mutexes etc. and it doesn't seem like there is any easy way to plug it in without editing a lot of the boost source. Is this an issue that has been raised before?
As Howard and Phil have posted, there is some scope for user-defined mutexes and locks (in particular) in the new boost trunk version (in order to match the new proposed standard library interface). However, fundamentally the code is tied to specific OS thread libraries --- you need to know how to launch a thread, how to allocate thread-local data, and how to implement mutexes and condition variables. e.g. boost::condition_variable_any will work with a user-defined mutex or lock, but it needs a platform-specific condition variable implementation internally. The code is split by platform, so you can add a new platform by detecting it in boost/thread/detail/platform.hpp, and putting the headers in boost/thread/<your-platform>. You then also need to modify the compiled lib: put new stuff in libs/thread/src/<your-platform> and modify the Jamfile to select your new code on that platform. It's not a trivial amount of work, but boost::thread doesn't have a "platform abstraction layer": it IS the platform abstraction layer. Anthony
participants (4)
-
Anthony Williams -
Eames, Andrew -
Howard Hinnant -
Phil Endecott