Support thread safety throughout the API

[mwpowellhtx]

I am using INFO, for example, to help record where tests are during execution. This is during a multi-threaded situation: server running in a separate thread. Clients connecting on the parent thread. When I sprinkle INFO throughout client and server code, the program crashes hard.

[repi]

Just ran into the same issue today as well but with REQUIRE, having support for thread safety in the assertion & logging macros would be really nice. For us it wouldn't have to be for all tests but some of our tests are specifically there to verify multithreaded code

[mwpowellhtx]

@repi I'm sure it's for REQUIRE as well. I just called out INFO as a first observation. Point is, thread-safety is A MUST.

[philsquared]

This need is one of the key drivers for Catch2 rebasing on C++11. Once Catch2 is fully released this will be one of the first major tasks - it's been on the wish-list for a looong time.

[mwpowellhtx]

@philsquared I'd say with the advent of std::thread, there really is no excuse for it to be a wish. In other words, that's not strong enough of a word, IMO.

[philsquared]

Exactly! Before Catch2, and thus C++11, we didn't have std::thread

[repi]

Sweet, we are all in agreement 👍

[mwpowellhtx]

@repi @philsquared Yes, I think we agree on the what. Now is a question of the when, which may necessarily be predicated on the who.

[Leandros]

How is that looking? Just ran into this issue, too.

[capsocrates]

I would love to see this addressed in Catch2.

[mwpowellhtx]

No idea; I've moved on to other non-C++ areas at the moment, so this is not on my radar screen apart from peripheral view.

[haydenmc]

Looks like this is still an issue - I have some places where I try to call UNSCOPED_INFO from a non-test thread and Catch2 blows up. It's a real bummer because detailed logs can be a huge help when trying to debug test failures.

Has anyone come up with a decent workaround? I've resorted to changing my logging to output via straight cout to help with debugging.

[ecorm]

Has anyone come up with a decent workaround? I've resorted to changing my logging to output via straight cout to help with debugging.

Perhaps a producer-consume queue where log messages are queued from your worker threads and then passed on to UNSCOPED_INFO in the main thread while it waits for your worker threads to finish?

[haydenmc]

That's a reasonable suggestion! Though it does introduce a little boilerplate into my test methods - it's better than my current situation.

I do hope native support for this arrives in Catch2 eventually. :)

[capsocrates]

My workaround was to create a global mutex and then have wrapper macros that lock that mutex, call the catch macro, and the unlock the mutex.

[ecorm]

My workaround was to create a global mutex and then have wrapper macros that lock that mutex, call the catch macro, and the unlock the mutex.

Mutexes are probably a more reasonable approach than a producer-consumer queue. I was thinking of an asynchronous logger when I had suggested that.

[mwpowellhtx]

TBH, a pub/sub pattern is going to guard its boundaries anyway. Probably internally, i.e. with a mutex.

[ecorm]

TBH, a pub/sub pattern is going to guard its boundaries anyway. Probably internally, i.e. with a mutex.

True, but directly using a mutex involves a lot less code than an entire producer-consumer queue that uses a mutex internally.

[mwpowellhtx]

Yes of course. The runtime and the scaffold being what it is. Of course, I am an OO guy, and I like the abstraction. From the consumer perspective, which is what any of us would be 99.9% of the time, don't have to think about the moving parts.

[cmorganBE]

Any status updates on this? I just bumped into it after running helgrind on a test suite that uses catch2.

[Viatorus]

@horenmar @philsquared and other. Any updates on this?

The documentation about Catch2 limitation states (https://github.com/catchorg/Catch2/blob/devel/docs/limitations.md#thread-safe-assertions):

Because C++11 provides the necessary tools to do this, we are planning to remove this limitation in the future.

What is the plan for this? C++11 is around 11 years now.

[bilderbuchi]

C++11 is around 11 years now.

I'm not sure what you are trying to achieve with this quip. I suspect that the maintainers are perfectly aware of the year C+11 was released, and that the delay is because of a shortage of available maintainer time, rather than language maturity. 😉

[bernhardmgruber]

I just hit the same limitation while tracking down thread sanitizer issues in the unit tests of our library (alpaka). We are basically calling CHECK(...) from two different threads. After a brief look into the code of Catch2 (where TSAN pointed me), it seems making just the assertion macros work could be a matter of just adding a mutex and a lock around the critical part. That would already be a big help!

[d7d1cd]

Hi all. I also encountered the problem of calling checks from different threads. Are there any progress in this direction?

[Oipo]

My +1: I'm also running into issues where I want to test my multi-threaded library, but I have to put in extra effort to make it work with Catch2.