[boost] Re: Re: boost.test thread safe bugs (and some fixes)

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-02-17 17:49:53

> > The code never promised to work in multithreaded environment, nor even
> > to be thread save. It is in my to-do list. Though recent hands in
> > several situations may require address some of these issues sooner.
>
> What?!?  Where's the big, bold disclaimer about that!

It's in to-do section in front page. Though you right. There should have
been explicit disclaimer about that.

> We have to have all
> of the Boost.Test library thread safe, because the Boost.Thread library
> depends on it.

It you are accessing Boost.Test interfaces only from one thread it may work
even with current implementation.

> > No. I don't think it's common situation. You don't usually create and
> > run test cases inside the other test case code.
>
> *I* had considered doing just this, in order to get a tree structure for
> dependent test cases.  Nothing in the documentation seems to indicate this
> is something that's not supported, and I think that would be the wrong
> answer in any event.

I already implemented changes that should allow reentrant usage of execution
monitor. So this is not a problem any more. On the other hand
I was thinking about implementing direct support for test cases dependency
inside the Boost.Test (next release). Would it be enough for you to be able
to specify that one test case should run only if some other one passed?

> >>To make this thread safe you would need to store the pointer in a
> >> thread local storage slot, BTW I don't think you can use boost.threads
> >> for this,
> > as
> >>it will create a dependency quagmire for status/Jamfile :-(
> >
> > I thought to introduce macro BOOST_MULTITHREADED_UNIT_TEST and guard all
> > usage of Boost.Thread with it. It does not create extra dependency and
> > should allow to build multithreaded version with bjam subvariant
> > feature.
>
> How would this work for the Boost.Thread library.  Boost.Test must be
> usable by Boost.Thread, and this means it must be thread safe with out
> using Boost.Thread.

1. Boost.Thread with depend on multithreaded version of Boost.Test.
2. Boost.Test will try to use minimal/basic part of Boost.Thread
functionality
3. The first test cases of Boost.Thread unit test will need to check that
the above basic functionality is working as expected. And only of these test
cases are passing, continue with rest of testing.

This is not unique situation. Boost.Test have the similar problems. It's
like in relativistic physics: one could not measure the exact value cause
the measure tools affect the measurement.

> Thread safety issues are very critical, AFAICT.  Boost.Threads depends on
> Boost.Test, and assumes it is thread safe.

I understand, William, your concern. But the Boost.Thread library is the
only library that needs thread-safe version of Boost.Test. Thread safety
will need to be addressed all over the place not only in execution_monitor.
Add here that I am not familiar with your library. As a result I would not
want to do this in a hurry. I promise to take care about it for the next
release. Would it be acceptable for you?

> --
> William E. Kempf

Gennadiy.