* Kostik Belousov <email@example.com> wrote:
> I was always curious whether our cv code guarantees that there is no
> a spurious wakeup. If the spurious wakeup can happen, then setting
> PTS_FINISHED before calling cv_broadcast() still does not solve
> the possible race.
> Assume that waiting thread is woken up, and ptsdrv_close() still did
> not set PTS_FINISHED. The ptsdev_read() locked the mutex, rechecked
> the condition (that is false still), and preempted for the
> ptsdrv_close() thread. This thread sets flag and issues broadcast.
> Then, the ptsdrv_read() thread is put to sleep, having lost a wakeup.
> I think that mutex shall be acquired around setting flag and wakeups.
> scheduled, it
Everything was already done correctly with respect to locking. All the
routines that use `pts_flags' already hold the per-TTY lock. The actual
problem is that KNOTE_LOCKED() (inside ptsdrv_*wakeup()) calls
pts_kqops_read_event() synchronously. This means that we must set
PTS_FINISHED on beforehand.
Ed Schouten <firstname.lastname@example.org>