Home > Net >  c block thread until condition on a thread-safe object is met
c block thread until condition on a thread-safe object is met

Time:10-08

I apologise in advance if my question is a duplicate, but I was not able to find a satisfying answer to my question.

I am dealing with the following (maybe silly) issue: I am trying to synchronise two threads (A and B), and I want to block the thread A until a condition is set to true by the thread B. The "special" thing is that the condition is checked on a thread-safe object (for instance, let's consider it to be a std::atomic_bool).

My naive approach was the following:

// Shared atomic object
std::atomic_bool condition{false};

// Thread A
// ... does something
while(!condition.load()) ;  // Do nothing
// Condition is met, proceed with the job

// Thread B
// ... does something
condition.store(true);      // Unlock Thread A

but, as far as I have understood, the while implies an active wait which is undesirable.

So, I thought about having a small sleep_for as the body of the while to reduce the frequency of the active wait, but then the issue becomes finding the right waiting time that does not cause waste of time in case the condition unlocks while thread A is sleeping and, at the same time, does not make the loop to execute too often. My feeling is that this is very much dependant on the time that thread B spends before setting the condition to true, which may be not predictable.

Another solution I have found looking on other SO topics is to use a condition variable, but that would require the introduction of a mutex that is not really needed.

I am perhaps overthinking the problem, but I'd like to know if there are alternative "standard" solutions to follow (bearing in mind that I am limited to C 11), and what would be the best approach in general.

Many thanks in advance for the help.

CodePudding user response:

Your use case is simple and there are many ways to implement that. The first recommendation would be to make use of condition variable. But it seems from your question that you would like to avoid that because of mutex. I don't have any profiling data for your use case, but mutex isn't costly for your use case.

In a multi-threaded environment, at some point of time, you would need some techniques to protect shared access and modification of data. You would probably need mutexes for that.

You could go for condition variable approach. It is by the standard, and it also provides function to notify all the threads as well, if your use case scales in future. Also, as you mentioned about "time", condition_variable also comes with variations of wait* functions where the condition could be in terms of "time". It can wait_for or wait_until a certain time as well.

About the while loop and a sleep_for approach, blocking a thread from execution and then rescheduling it again isn't that cheap if we are counting in terms of milliseconds. The condition variable approach would be better suited in this case, rather than having the while loop and an explicit call to sleep_for.

CodePudding user response:

How about using some sort of a sentinel value to check if the conditions of thread B are true to unlock thread A and synchronize both of them once the condition is met.

  • Related