Date: Mon, 14 Jun 2004 11:53:13 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-smp@FreeBSD.org Subject: Re: Question about cv_signal(9) (never mind) Message-ID: <XFMail.20040614115313.jdp@polstra.com> In-Reply-To: <200406141444.38269.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14-Jun-2004 John Baldwin wrote: > On Saturday 12 June 2004 08:12 pm, John Polstra wrote: >> On 12-Jun-2004 John Polstra wrote: >> > [Why does a caller to cv_signal(9) have to hold the associated mutex?] >> >> Never mind. I understand now. It allows the implementation to >> avoid doing any locking internally. That seems perfectly >> reasonable, and I withdraw my question. > > To be honest, it's also largely there to try to keep people from writing code > that can lose wakeups. The count optimization came later. If the > optimization of dropping the lock is more important and we think that people > really won't make the mistake of not using locks when they should to avoid > the lost wakeups then we could drop the count optimization and allow > cv_signal() to not require the lock perhaps. It seems to me that some sort of mutual exclusion is needed when manipulating the cv structure and the associated sleep queue. If the user doesn't provide it then the implementation will have to provide it internally. So unless there is a cheaper kind of mutual exclusion that can be used inside the implementation, your current solution seems the best to me. I had never thought through the need for some kind of mutual exclusion, and the papers that describe the optimization I mentioned simply ignore it and its performance implications. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20040614115313.jdp>