一个实现信号量的建议，为什么是错误的？

Question

I found this slide in my digital textbook (I tried to copy the text but it won't allow me).

What is that "lost wake" problem? I tried to search in many ways but couldn't find anything regarding this.

Answer 1

To expand on @stark's comment, suppose that thread 1 called wait() and gets preempted immediately after unlocking, but before calling block() . Assume that thread 1 is the only thread in the queue. Next, suppose that a thread 2 calls signal(), calls wakeup(), and returns. Note, that the call to wakeup() does nothing since thread 1 has not yet called block().

Now, when thread 1 executes, it will call block(), and may potentially wait forever if no process calls signal() again. The call to wakeup() by thread 2 was lost since thread 1 was on the queue, but wasn't blocking yet.

Caveat

This really depends on system implementation. It is feasible for wakeup() to buffer a signal if the corresponding process is not yet blocked. However, I am not aware of systems that do this.

POSIX pthread API

The lost-wakeup problem is mostly sidestepped when using the POSIX pthread API. Specifically, the condition variable should be protected with a lock as well. This is why the man page of pthread_cond_wait says:

The pthread_cond_wait() function atomically blocks the current thread
waiting on the condition variable specified by cond, and releases the
mutex specified by mutex.

The keyword above is atomically .

Further reading.

Follow-up Questions

1. Can you explain more what wakeup and block really are?

wakeup() and block() are syscalls. block() is used by a process to block itself until another process wakes it up. This may be done, for example, to wait until another element can be removed from a queue. wakeup() is used to wake up a process that previously called block().

2. Why this can't be solved by moving lock() after block() ?

Moving lock() after block achieves nothing, and will cause deadlock. If you meant moving unlock() after block(), then that won't work because the process will block while holding the lock, and now no other process can wake up the blocked process.