Silly me - I should have looked in the Boost.Test Open Issues page a couple of days ago instead of wasting my time trying to solve some multi-threading problems in my own code. So a couple of enhancement requests (for Gennadiy, or appropriate person): 1. Please state clearly in the Boost.Test documentation that it is not thread-safe. I looked all through the pages (both the current release and the 1.31 release) but the only place I find mention of thread-unsafety is in the Open Issues page. The FAQ page would also be a good place to mention Boost.Test thread-unsafety, besides the main page (and places like Usage Recommendations, Examples, Compilation, etc). 2. Please consider adding thread-safeness to the Boost.Test libraries. I know this is not a simple request, and there may be other priorities ... but many of my (and my team's) unit tests are multi-threaded, and it's a shame to not be able to use Boost.Test (or even know which, if any, parts are thread-safe). It's a nice testing framework, IMO. Note that I don't need the whole library itself to be threaded, just to be able to do things like BOOST_MESSAGE and BOOST_EQUAL within my own testing threads. (I'll offer whatever help I can provide, within the constraints of my available time.) Many thanks! Cliff
1. Please state clearly in the Boost.Test documentation that it is not thread-safe. I looked all through the pages (both the current release and the 1.31 release) but the only place I find mention of thread-unsafety is in the Open Issues page. The FAQ page would also be a good place to mention Boost.Test thread-unsafety, besides the main page (and places like Usage Recommendations, Examples, Compilation, etc).
Ok. Will do.
2. Please consider adding thread-safeness to the Boost.Test libraries. I know this is not a simple request, and there may be other priorities ... but many of my (and my team's) unit tests are multi-threaded, and it's a shame to not be able to use Boost.Test (or even know which, if any, parts are thread-safe). It's a nice testing framework, IMO. Note that I don't need the whole library itself to be threaded, just to be able to do things like BOOST_MESSAGE and BOOST_EQUAL within my own testing threads. (I'll offer whatever help I can provide, within the constraints of my available time.)
While you waiting my recomendation is very simple: wrap Boost.Test test tools access using your own locks available. MY_MESSAGE( ... ) \ do { \ Lock( shared_mutex )\ BOOST_MESSAGE( ... )\ } while( 0 )\ /**/ MY_CHECK_EQUAL( ... ) \ do { \ Lock( shared_mutex )\ BOOST_CHECK_EQUAL( ... )\ } while( 0 )\ /**/
Many thanks!
Cliff
Gennadiy.
While you waiting my recomendation is very simple: wrap Boost.Test test tools access using your own locks available.
Thanks for the suggestions and taking the requests, Gennadiy ... I was thinking about this (wrapping with my own locks) after finding out the thread-unsafeness, with the only caveat that it does significantly affect the thread timing, which can mask any underlying problems I'm trying to find. I realize that if you add underlying mutex locks into Boost.Test, you're doing some of the same thing yourself ... the biggest difference is that you know which portions need the locks, and which are already thread-safe and don't need additional locks (of course I can always read the Boost.Test code and do the analysis myself, but at that point I'd just as soon volunteer my time to help you with that work. :) ). Any real multi-threading experts are welcome to abuse my assumptions and approaches - I've realized over the last year or two how complex the subject is, and how much I don't yet know ... :) (On a side note, we're using ACE Threads, not Boost Threads, primarily for the specific platform support that ACE Threads provides - Solaris, Vxworks, Win32, Linux, etc.) Cliff
On 5/6/05, Cliff Green <cliffg@codewrangler.net> wrote:
While you waiting my recomendation is very simple: wrap Boost.Test test tools access using your own locks available.
Thanks for the suggestions and taking the requests, Gennadiy ... I was thinking about this (wrapping with my own locks) after finding out the thread-unsafeness, with the only caveat that it does significantly affect the thread timing, which can mask any underlying problems I'm trying to find [...]
(On a side note, we're using ACE Threads, not Boost Threads, primarily for the specific platform support that ACE Threads provides - Solaris, Vxworks, Win32, Linux, etc.)
It ought to be no problem to mix the two, e.g. using Boost.Thread locks to guard Boost.Test usage inside of running ACE_Thread threads. They end up using the same platform-specifc threading, etc. primitives on all of the mutually-supported platforms (not sure about Boost + VxWORKS) I agree with Cliff and propose that this thread-safety (or thread-awareness) issue is best handled inside of the Boost.Test Test Tools macros themselves. I think the code that a user has to write to protect Test Tools macro invocations vs. the code that could be generated by the Test Tools doing their own protection might be meaningfully different. For example: scoped_lock lk (mtx); BOOST_CHECK_EQUAL (some_operation(), some_value); is quite different from (naively expanding BOOST_CHECK_EQUAL - I don't know exactly what it does): if (some_operation () != some_value) { scoped_lock lk (mtx); // a test failed, so keep track of that and log an error BOOST_ERROR ("var != value"); } The former might mask subtle (or not-so-subtle) bugs in some_operation () that the latter would leave exposed. Pretty much line-for-line this is the net effect of a patch I recently submitted to correct thread-safety issues with the Boost.Thread test programs. I think this should be a user-selectable feature, requiring users who want it to define a macro (eg. BOOST_TEST_THREAD_SAFE?) before including the Boost.Test headers. Perhaps it could be automatically enabled when BOOST_ENABLE_THREADS was defined. Thoughts? -- Caleb Epstein caleb dot epstein at gmail dot com
"Caleb Epstein" wrote:
I agree with Cliff and propose that this thread-safety (or thread-awareness) issue is best handled inside of the Boost.Test Test Tools macros themselves. I think the code that a user has to write to protect Test Tools macro invocations vs. the code that could be generated by the Test Tools doing their own protection might be meaningfully different. For example:
[snip]
Thoughts?
A test framework should stay as non-obtrusive as possible. Does thread safety in Boost.Test mean linking yet another *.cpp files or libraries? /Pavel
participants (4)
-
Caleb Epstein -
Cliff Green -
Gennadiy Rozental -
Pavel Vozenilek