Semaphore=Mutex+CondVar (Concurrency wizards needed)

All those unwraps do is propagate panics while the lock is held to other threads using the Semaphore. As there is no possibility here of external code running with the lock held, any such panics are a bug in this code— The only such panics will be fairly catastrophic conditions like out-of-memory, for which there’s no good recovery procedure.

1 Like

Monitors in Java are still susceptible to spurious wakes. Or rather, the conditional variable associated with Java monitors are. This is present on the Java docs of the wait() method in Java.

Interesting link you posted. However, I don't understand why the author recommends the usage of monitors over semaphores. Semaphores are used for signalling between threads,while monitors (i.e. Java mutexes) are for mutual exclusion. Its comparing apples with oranges. Off course you can implement a semaphore with a monitor and a condvar (hence this post), but they are used for different things.

I do specially agree with the section regarding semaphore drawbacks:

There is no control or guarantee of proper usage.

Indeed! That is why a semaphore of size 1 is different from a mutex, contrary to what we see spread around the internet and even books. A mutex can only be released by the thread that holds the lock. A semaphore can be released from the outside. It requires the users to not mess up!

I am doing that in my repo. Happy to share ideas if you jump into doing that.

Not sure I understood the conclusion.
Are you saying that the usage of the panics here are fine, or that they are a bug?

I understood that they are fine, since there is no external code running with the lock held, and so no possibility for panics unless it is a "catastrophic" condition, for which there is no escape anyway.
Did I understand your point correctly?

Panic is a choice of the library writer. Right now Rust language is being considered to be included inside the Linux kernel, and of course a kernel cannot panic in response to something as trivial as something went wrong in a single thread. Panic could a perfect solution in an user app. It all depends on if you want to write something experimental, or something solid enough for kernel use!

Spurious wakes in a monitor is generally harmless; as long as this is a rare event the spuriously waked thread will just go back to sleep waiting on the condition variable.

Actually when I program a monitor data structure myself, usually I limit sleep time to 10 seconds or less, just in case if there are missed wake-ups as well; fault tolerance is important.

I don't mean to be confrontational, but what do you mean by generally harmless? Either it works all the time, or it doesn't, right? And if it doesn't, then it would need the while guard to protect it and make it work all the time.
I understand that there are problems where spurious wakes are not a problem, but for many problems they are. Certainly for the problem of developing a semaphore, whereby a spurious wake would allow additional threads in.

How does the spuriously waked thread go back to sleep exactly in the absence of a while guard?
By definition, if the thread awakes, it continues where it left off.

By comments concern java monitors. Maybe we are speaking about different things.

AFAIK, Monitors are objects + built-in condvar + built-in. mutex, totaling all: synchronized, wait, notify, notifyAll, so they can be used for both signaling and exclusion.

CondVars require user to check condition they are waiting for after every wakeup, and sleep again if still not fulfilled. That's why spurious wakeups are harmless - the woken thread just goes back to sleep. AFAIK, the reason is that it's much easier/performant to implement wakups that in certain situations can result in spurious wakups, so it's a better API to leave it to the user to wrap it in a loop.

When I say "generally harmless" it is in the context of a monitor implementation, not a Semaphore.

I found out another interesting trivia, that the condition variable in the parking_lot crate is not subject to spurious wake-ups. That would fit better in the Semaphore use-case. Unfortunately the mutex in the parking_lot does not detect panics in the peer threads. Some work-arounds should be possible here.

Located Rust Semaphore and Monitor implementations on Github. You can compare them.

Semaphore
Monitor

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.