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

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

> If you consider a test suite a test case (which should be how it is, no?),
> then yes, that's all I'd need.

Yes. test suite is a test case.

> > 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
>
> There's no "minimal/basic part" of Boost.Thread that doesn't need testing.

I did not mean that it does not need testing. What I meant is that I will
try to use only small part of Boost.Thread functionality.
What I propose is that we first check that namely this part is working (It
could be part of Boost.Tet or BoostThread unit test)
And then move on with rest of your testing.

>  If I can't rely on it working in my own regression testing, I ceratainly
> can't rely on it being a part of the underlying test framework.  I know
> this means more work for you, but there's not much to be done about it.
> You can sacrifice performance, however, in a testing framework.  So you
> can probably get by with nothing more than a simple mutex and a TSS
> concept with out implicit cleanup, which should be fairly trivial for you
> to implement.

I would really prefer not to reinvent the wheel with portable implementation
of Mutex and TSS.

> > 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.
>
> How do I test the "minimal" portion if I can't use the testing framework?

There are several choises here. You may need to know know Boost.Test is
using mutex and tss. Or you may rely on  Boost.Test unit tests that I will
implement to validate multithreaded usage. For example, start 2 threads and
throw an exceptions in both of them (making sure that there is no race
conditions). This way  we may check that execution monitor jump buffer is
located in thread specific storage. And so on with every usage of
Boost.Thread. An alternative is to write several simple tests for the part
of Boost.Thread that used by Boost.Test without usaing of Boost.Test. Once
they passed we may be confident with usage of Boost.Test for further
testing.

> Boost.Threads is the only library that needs thread-safe versions of
> Boost.Test *TODAY* (at least that are part of the actual Boost project,
> but Boost.Test is also being used outside of the Boost project, and I
> won't begin to claim that I know they don't need thread-safe versions).
> As for not doing it in a hurry... I understand what you're saying, but
> this sounds like it jeapordizes this and future release schedules.  The
> deadlocks reported in the Boost.Threads tests can't be reproduced by
> myself with any of the compilers I have available on any of the 3 machines
> and 2 OSes I have.  This makes diagnosing problems extremely difficult,
> and if I can't trust that the problems aren't in the testing framework,
> it's even more difficult.

As I sad I will make sure it is resolved till next release. Today is
supposed to be a branch. And discussed changes neither simple nor small.
Meanwhile I take a more detailed look on what modules are affected (You are
welcome to take a look youself, cause I am sure you better familiar with
thread safety issues).

Gennadiy.