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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-18 18:21:11

Gennadiy Rozental said:
>> > 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.

Again, how do you "test it is working" if we can't use the Boost.Test
framework!  We're in a catch-22 situation so long as you use Boost.Thread
in Boost.Test.

>>  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.

I understand you not wanting to do so, but I see no alternative.

>> > 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.

How do you create a thread here if we can't prove that the Boost.Thread
creation works portably?  You'll still wind up "reinventing the wheel"
here, you're just choosing to implement thread creation instead of the
mutex and TSS.  From my POV it would be easier to do the mutex and TSS,
but hey, I don't care as long as you can prove that the testing framework
works *before* I start using it to test Boost.Threads.

-- 
William E. Kempf