Date: Wed, 09 Nov 2016 08:32:25 -0800 From: John Baldwin <jhb@freebsd.org> To: Hans Petter Selasky <hps@selasky.org> Cc: Oleksandr Tymoshenko <gonzo@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r308424 - head/sys/arm/broadcom/bcm2835 Message-ID: <2064206.nvhhXHc9vW@ralph.baldwin.cx> In-Reply-To: <5c170b6b-1189-4712-ffdd-653cc6b8c59e@selasky.org> References: <201611071738.uA7HceYu045944@repo.freebsd.org> <3214848.geWV8qu7rM@ralph.baldwin.cx> <5c170b6b-1189-4712-ffdd-653cc6b8c59e@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, November 09, 2016 05:10:09 PM Hans Petter Selasky wrote: > Hi, > > On 11/09/16 16:02, John Baldwin wrote: > > On the other hand, doing the wakeup outside of the lock > > avoids preempting during the wakeup only to immediately block on the lock and > > switch back to the thread that did the wakeup. > > This can be predicted and avoided by the turnstiles iff cv_signal() is > used under a lock. Else not. It isn't predicted and avoided by turnstiles. In particular, the cv_signal has no idea what lock is associated, so it can't try to do something "smart" and move the thread from the sleepq to the lockq. You will pay the double context switch. > Won't doing the wakeup outside the lock cause double preemtion? First at > mtx_unlock() and then inside cv_signal()/cv_broadcast(). No. The other thread can't be blocked on both the mutex and cv. If the thread is blocked on the mutex and you preempt to it, then it won't ever bother sleeping on the cv anyway (and the cv_signal will be a nop once the awakening thread resumes). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2064206.nvhhXHc9vW>