Is boost test thread-safe?
I searched a bit but was unable to find a reasonable answer. Is the test framework thread-safe? I am asking since when I do threaded tests I get weird and seemingly random output. By thread-safe I don't mean that I have multiple tests running at the same time, but simply that I have tests which involve multiple threads. For example: BOOST_AUTO_TEST_CASE( threaded ) { thread a( func_a ); thread b( func_b ); a.join(); b.join(); } void func_a() { ... BOOST_CHECK_EQUAL( 123, var ); } It appears that using the BOOST_CHECK tools from the thread causes problems. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.
edA-qa mort-ora-y
It appears that using the BOOST_CHECK tools from the thread causes problems.
Yes. This is indeed the case. Boost.Test (for now at least) do not have any dependencies on threading libs. Meanwhile, you can write simple wrappers around Boost.Test testing tools you are using, which will lock some global lock and perform the action of the tool. Gennadiy
On 04/25/2011 07:42 AM, Gennadiy Rozental wrote:
Yes. This is indeed the case. Boost.Test (for now at least) do not have any dependencies on threading libs. Meanwhile, you can write simple wrappers around Boost.Test testing tools you are using, which will lock some global lock and perform the action of the tool.
I tried to write a few wrappers, it isn't so trivial. The main issue is that we can't be locking a mutex /unless/ the test condition fails, otherwise it would significantly interfere with the test. So my wrappers first do the check and then call the normal boost tool. However, certain things like CHECK_CLOSE I couldn't figure out. I found the "is_close" static instance but couldn't get it working correctly. Is there perhaps a standard way that I can just do the tool test and have a bool result returned? That would make writing the wrappers a lot simpler, I could just make them look like this: #define THREAD_CHECK_CLOSE( a_, b_, p_ ) \ if( !BOOST_BOOL_CLOSE( (a_), (b_), (p_) ) ) \ BOOST_CHECK_CLOSE( (a_), (b_), (p_) ) With locking added inside the if statement. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.
I tried to write a few wrappers, it isn't so trivial. The main issue is that we can't be locking a mutex /unless/ the test condition fails, otherwise it would significantly interfere with the test.
Why would that be the case? all that will do is stop two validation calls from overlapping. What sort of problems would that cause to the test itself? (I haven't double checked, but if boost uses exceptions to propagate failures, you might have to deal with that if these things happen on background threads)
edA-qa mort-ora-y
However, certain things like CHECK_CLOSE I couldn't figure out. I found the "is_close" static instance but couldn't get it working correctly.
There is check_is_close and it's being invoked like this: check_is_close( d1, d2, tolerance ) and it returns predicate_result, which you can query if check was successful. Gennadiy
participants (3)
-
David Blaikie -
edA-qa mort-ora-y -
Gennadiy Rozental