From owner-freebsd-current Mon Jul 8 18: 7: 7 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3114237B401 for ; Mon, 8 Jul 2002 18:07:02 -0700 (PDT) Received: from web20907.mail.yahoo.com (web20907.mail.yahoo.com [216.136.226.229]) by mx1.FreeBSD.org (Postfix) with SMTP id D745C43E42 for ; Mon, 8 Jul 2002 18:07:01 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020709010645.51137.qmail@web20907.mail.yahoo.com> Received: from [218.97.164.167] by web20907.mail.yahoo.com via HTTP; Mon, 08 Jul 2002 18:06:45 PDT Date: Mon, 8 Jul 2002 18:06:45 -0700 (PDT) From: David Xu Subject: Re: Timeout and SMP race To: John Baldwin Cc: Julian Elischer , "freebsd-current@FreeBSD.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'll work out a patch to see if my idea works. David Xu --- John Baldwin wrote: > > 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 <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message