You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi elfring and thanks for the feedback. I don't think an atomic operation is really needed in this case. The reason is that only one the main thread is supposed to change the boolean ´threads_on_hold´. Thus I would think that there is not any problem with having it as a normal variable.
I can think only of one scenario that might be an issue; when the main program has more than one threads. Still, realistically, I can't imagine that being a big problem:
If two threads they both set the boolean to 0, then there is no problem. The second thread re-setting the boolean is actually not changing anything.
If two threads they both set the boolean to 1, then there is no problem. The second thread re-setting the boolean is actually not changing anything.
If one sets the boolean to 0 and the other to 1 still there is no problem. The reason is that the boolean will be set to either one of the two and thus one of the two threads is correct. In such a case it's more of a program design issue and I would look more into that.
If you think I missed something, feel free to comment.
An atomic update will be needed in your implementation because the mentioned variable is used for data exchange within a signal handler.
Thus I would appreciate that a data type definition which is recommended for such a purpose will be reused.
The variable "threads_on_hold" should use the data type "sig_atomic_t", shouldn't it?
The text was updated successfully, but these errors were encountered: