Date: Wed, 4 Jul 2001 11:38:04 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Matthew Jacob <mjacob@feral.com>, Jake Burkholder <jake@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys systm.h condvar.h src/sys/kern kern_ Message-ID: <200107041838.f64Ic4V46525@earth.backplane.com> References: <XFMail.010704111445.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>: sleep on A ....
:>: idle ....
:>: lock A
:>: mwakeup A (drops A before doing actual wakeup)
:>: lock A
:>
:> Huh? In the above example, why not simply release A before calling
:> the wakeup function in the above example? mwakeup is not required at all.
:> You may have to interlock sleeps, but you certainly do not have to
:> interlock wakeups. Try presenting another example.
:
:Releasing the lock before the wakeup leaves a window open (interrupts can make
:small windows into large ones) during which the state of the subsystem can
:change before the wakeup is delivered, possibly resulting in a bogus wakeup
:being sent. However, I'm not sure that this window is actually a problem, and
:I'm less convinced than when mwakeup() was first proposed.
We use this trick (clear variable then wakeup and who cares if there is
a window there or not) all over the codebase.
:> In the non-preemptive case, on a UP system, the first task is allowed
:> to wakeup the second, then unlock, then sleep, and then will switch to
:> the second task. All without any need for a mwakeup() function.
:>
:> In the preemptive case, on a UP system, you have to have mwakeup() to
:> avoid the two extra context switches.
:
:Not if you release the lock before wakeup as you suggest.
:
:> In the non-preemptive case, on a MP system, the scheduling overhead
:> will take far longer then it takes the original thread to release the
:> mutex so it does not matter whether the mutex is released before or after
:> the wakeup.
:
:Unless you get an interrupt in between the wakeup and lock release.
A window which has no real effect other then to cause one wakeup out
of several million (or billion) to delay another thread. That verses
the overhead of doing some sort of interlock on every single wakeup
means you are actually making things worse with the interlock.
:
:Note that the problems associated with preemption mirror those problems found
:in SMP systems and have to be solved anyway.
:
:> My assertion is that mwakeup() is solving a problem created by the
:> preemption in the first place and that assertion still holds true.
:
:No. If you must hold the lock across wakeup(), then you have the same problem
:with contending on the lock in the SMP case as in the preemptive case. If you
:release the lock before wakeup(), then both cases each have the same window
:open during which the state of the subsystem can change between the lock
:release and the wakeup being delivered. Preemption is an SMP environment on a
:UP system. The problems encountered by preemption will be encountered in SMP
:systems anyway.
No, if you wakeup a thread and then release the mutex in a non-preemptive
case, even if you have multiple idle CPUs available, the scheduling and
switching overhead in the thread being woken up will be vastly greater
then the time it takes for the caller to release the mutex. So by the
time the newly woken up thread actually checks the mutex, it will have
already been released in the vast majority of cases. The cache mastership
changes between the two cpu's alone is probably sufficient to cover the
time.
-Matt
:--
:
:John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107041838.f64Ic4V46525>