From owner-freebsd-arch Thu Jul 11 22:15:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AA5F37B400; Thu, 11 Jul 2002 22:15:30 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 757A143E54; Thu, 11 Jul 2002 22:15:29 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA80888; Thu, 11 Jul 2002 22:05:32 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g6C54m736085; Thu, 11 Jul 2002 22:04:48 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200207120504.g6C54m736085@arch20m.dellroad.org> Subject: Re: Timeout and SMP race In-Reply-To: <200207101815.g6AIFDm28655@arch20m.dellroad.org> "from Archie Cobbs at Jul 10, 2002 11:15:13 am" To: Archie Cobbs Date: Thu, 11 Jul 2002 22:04:48 -0700 (PDT) Cc: John Baldwin , davidx@viasoft.com.cn, freebsd-arch@FreeBSD.ORG, julian@elischer.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Archie Cobbs writes: > FWIW, here is an API I've used before. This handles all race > conditions and the 'other thread' question. I should also mention that if we were to implement this API it may be useful to generalize it to handle arbitrary events rather than just timeout events (this is how I've implemented it in our application). For example, 'user defined' events could be triggered from any thread simply by calling a trigger function. This would be like an 'event' version of tsleep(): instead of sleeping for the event, a callback function (handler) that you provide would be called when the event occurs. The key is that you get the same benefits mentioned before, i.e., your mutex would already be held when your handler is invoked, there's no race between the handler and cancelling the event, etc. Event-based programming is more efficient than threads when you don't require a stack to store your state while waiting for the event. Not sure how many instances there are in the kernel that could benefit from this however. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message