-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementation of pthread_cond
#661
Comments
I remember that we were puzzled a lot about those Now I assume that you talk from a more practical point of view where you do not want to rely on spuriousness to argue about termination, right? Do you have a concrete example in mind where you expect Dartagnan to give a different result? EDIT: Maybe I should also add that our support for |
Well, yes and no. The spec says that spurious wake ups are possible, but I don't think that "always" should be understood with "eventually always" or something, ie, that if you just wait enough all waiters have to be waken up. So I think that the situation of having N waiters and sending a N-1 signals should trigger a deadlock error. The real implementation of the signal might just always do broadcasts, yes, but for the verification we need to check the other case.
No worries here. I think one can live with that. |
I totally understand that for liveness issues you don't want to have a "fairness assumption" about spurious wakeups, i.e., just because one thread can spuriously wake up infinitely many times, it actually has to do so. I'm not sure how to model this yet. For single signals, it would be fine to have each thread spin in a CAS-loop that waits for a signal and atomically consumes it. |
It seems that the current implementation of
pthread_cond
does not properly capture cases where one would forget to signal or broadcast the waiters.The implementation of
pthread_cond_signal
points topthread_cond_brodcast
. The implementation ofpthread_cond_broadcast
is empty. The implementation ofpthread_cond_wait
is apthread_mutex_unlock(); pthread_mutex_lock();
. That is actually quite simple and nice. It can already capture some issues. But as said above, it actually always enventually wake up every waiter.The text was updated successfully, but these errors were encountered: