svn commit: r186382 - head/sys/kern

[Ed Schouten]

Hello Kostik,

* 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>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20081221/dd98c0af/attachment.pgp