svn commit: r186382 - head/sys/kern
ed at 80386.nl
Sun Dec 21 22:52:35 UTC 2008
* Kostik Belousov <kostikbel at gmail.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 <ed at 80386.nl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20081221/dd98c0af/attachment.pgp
More information about the svn-src-head