Gennadiy Rozental said: >> > 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.
But that's an impossibility. I have to test from multiple threads (or what would the point be?!?). Now certain parts of the interface might be restricted to a single thread... but I don't feel comfortable even with that. >> > 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? If you consider a test suite a test case (which should be how it is, no?), then yes, that's all I'd need. >> >>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 There's no "minimal/basic part" of Boost.Thread that doesn't need 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. > 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? > 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. If I can't "measure" the correctness of Boost.Threads, because Boost.Test affects the measurement, then what good is it? >> 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? 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. -- William E. Kempf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
