Date: Tue, 3 Jul 2001 18:26:56 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: 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_synch.c kern_condvar.c Message-ID: <200107040126.f641Qun40260@earth.backplane.com> References: <20010703174807.R29024-100000@wonky.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Tue, 3 Jul 2001, Jake Burkholder wrote:
:
:> jake 2001/07/03 17:32:51 PDT
:>
:> Modified files:
:> sys/sys systm.h condvar.h
:> sys/kern kern_synch.c kern_condvar.c
:> Log:
:> Implement mwakeup, mwakeup_one, cv_signal_drop and cv_broadcast_drop.
:> These take an additional mutex argument, which is dropped before any
:> processes are made runnable. This can avoid contention on the mutex
:> if the processes would immediately acquire it, and is done in such a
:> way that wakeups will not be lost.
:
:
:I'm a bit confused by this last statement. Wakeups should never be lost
:not matter what.
:
:I can see that it's possible you could get contention if the cv_signal
:or wakeup causes a reschedule on another CPU right away. Is there any
:empirical measurements showing this happening?
:
:Don't get me wrong- seems to be a useful variance, but we're starting to
:look a bit like NT/Win32 here.
:
:-matt
This call seems to implement for wakeup() what msleep() implements for
tsleep(), and it makes sense in that context, but it is solving a problem
by obfuscating the SMP code even more then it already is, all in the
name of avoiding priority inversions using an 'instant-gratification'
model, which I consider to be fatally flawed. It is a terrible idea
to rip a perfectly happy kernel thread out from under itself just to
satisfy some flawed notion that running the just-woken-up higher-priority
process is more important. It may be *theoretically*, and it certainly
can be argued for interrupts, but the reality is that you are actually
slowing the whole fraggin machine down by blowing the L1 and L2 cpu
caches and it is NOT something to be done lightly, certainly not in a
general non-interrupt thread case. And you are opening yourself up
to many, many potential degenerate wakeup/rip-up cases that never
existed before.
The solution is NOT to try to add yet more APIs to work around the
inefficient results. The solution is to rip out the flawed concept
that is causing this mess in the first place. mwakeup() is a fundamental
and unnecessary obfuscation of the code.
I brought this up at the kernel meeting and I am bringing it up again.
If this continues then in another 6 months we are going to have dozens
of wierd one-off API calls to handle the dozens of special cases these
mechanisms are creating. Hell, this doesn't even cover the common case
of holding more then one mutex! We already have a proliferation of
mutex lock type calls. It is already bad enough right now.
msleep() I can understand (at least it's flaw is similar to the flaw
the spl() mechanism had in regards to thread sleep/wakeup
synchronization). mwakeup() makes sense only in a very twisted way.
-Matt
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?200107040126.f641Qun40260>