Date: Mon, 08 Jul 2002 20:46:53 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: David Xu <bsddiy@yahoo.com> Cc: Julian Elischer <julian@elischer.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: Timeout and SMP race Message-ID: <XFMail.20020708204653.jhb@FreeBSD.org> In-Reply-To: <20020708235244.76569.qmail@web20902.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020708204653.jhb>