Hello Kostik,
* Kostik Belousov <kostikbel@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@80386.nl>
WWW: http://80386.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAklOyLEACgkQ52SDGA2eCwWGxgCeLeE1EjUXUIcQJVjATJ33rl8q
3zUAmweHAbe/WCkGRwIB/UXJfKQ/igYn
=otm5
-----END PGP SIGNATURE-----