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
