Re: [boost] Re: [Test] Thread-safety

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-05-06 22:50:34

On 5/6/05, Cliff Green <cliffg_at_[hidden]> 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