Date: Wed, 04 Jul 2001 11:14:45 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> 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: <XFMail.010704111445.jhb@FreeBSD.org> In-Reply-To: <200107041739.f64HdN945537@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Jul-01 Matt Dillon wrote: > >:> >:> 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' >: >:Actually, Matt, this doesn't requrie preemption in order to be seen at all. >:It's really quite simple: >: >: cpu A cpu B >: lock A .... >: sleep on A .... >: idle .... >: lock A >: wakeup A >: block on A .... >: unlock A , unblock thread that was on cpu A >: lock A >: >:With mwakeup, this becomes: >: >: cpu A cpu B >: lock A .... >: 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. > 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. 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. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010704111445.jhb>