On 08-Jul-2002 David Xu wrote:
> I want to set an flag bit CALLOUT_PROCESSING in callout.c_flags,
> before softclock() releases callout_lock and start requesting
> callout.c_func(), so callout_stop can find that callout is processing
> by softclock and wait, after softclock processed the callout, it
> resets the flag and wakeup callout_stop thread, of course, if
> callout_stop is being called in softclock() thread, it should avoid
> waiting, it is easy to detect.

This doesn't work.  The callout function can do a callout_reset() on
itself to reschedule itself.  Well, if all the various callout functions
check for the processing flag it might work.  Then you have to figure out
how to properly wait.  You can't use a cv as they don't work with spin
mutexes.  Hmmm, this is one of the times I wish we could wait on a cv with
a spin mutex.  You could do something evil where you had a cv and a mutex,
unlocked callout lock, locked mutex, locked callout lock, rechecked
condition, then blocked if needed.  Similar evilness required when doing
a wakeup as well.  We can cheat in the endtsleep() case because we know
what thread to wakeup as well.  We don't easily have that in the general
case unless we bloat struct callout a bit.


John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to