> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost