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