From owner-freebsd-current Thu Jul 11 20:37:50 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 37DF437B400 for ; Thu, 11 Jul 2002 20:37:48 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B21543E54 for ; Thu, 11 Jul 2002 20:37:47 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.12.4/8.11.5) with ESMTP id g6C3bKbA002490; Thu, 11 Jul 2002 21:37:24 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200207120337.g6C3bKbA002490@aslan.scsiguy.com> To: Jonathan Lemon Cc: Bruce Evans , bsddiy@yahoo.com, current@FreeBSD.ORG Subject: Re: Timeout and SMP race In-Reply-To: Your message of "Thu, 04 Jul 2002 11:53:26 CDT." <20020704115326.R1020@prism.flugsvamp.com> Date: Thu, 11 Jul 2002 21:37:20 -0600 From: "Justin T. Gibbs" 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 believe I had this conversation with Justin Gibbs earlier; he told >me that the callout consumers (network, cam) had to be aware of the >race and handle this if it matters. I don't particularly like complicating >the callout handlers as illustrated above, though, so if a better scheme >is possible, that would be nice. If callout_stop() is always called from a context that can block and we desire the semantics that upon return from callout_stop(), you are not in the callout handler, it seems that this should be quite easy to achieve. Just track the state of the callout from "commit" and "return", via some flags locked by a global mutex. If a callout_stop is called between "commit" and "return" (just look at a global indicating the currently running callout protected by this mutex), put the thread on a list to be woken by the thread issuing the callout. To handle the case of a reschedule performed by the callout itself, the woken up caller to callout_stop() will have to loop through the test again. In all cases, the global mutex is only held for very short operations as a leaf mutex. >tsleep() is only called from process context With interrupt threads, isn't "process context" a bit of a misnomer? Would it be acceptable for the "interrupt threads" that perform callout_stops to block waiting for them to take effect? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message