From owner-freebsd-smp Wed Jun 30 19:19:23 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id AB19F14F22 for ; Wed, 30 Jun 1999 19:19:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA42502; Wed, 30 Jun 1999 19:19:18 -0700 (PDT) (envelope-from dillon) Date: Wed, 30 Jun 1999 19:19:18 -0700 (PDT) From: Matthew Dillon Message-Id: <199907010219.TAA42502@apollo.backplane.com> To: Matthew Dillon Cc: Terry Lambert , bright@rush.net (Alfred Perlstein), smp@FreeBSD.ORG, tlambert@primenet.com Subject: Re: async call gates References: <199907010100.SAA13352@usr09.primenet.com> <199907010154.SAA42283@apollo.backplane.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : So in my embedded OS I had a domsg() and a sendmsg() API. The user : process constructs the message and calls one or the other entry point. : If the user requested a synchronous call AND the device happens to run : the request synchronously, the OS doesn't bother even queueing the : message up to the device. It calls the device entry, sees that the : device ran the message synchronously, and returns. The result is an : operation that runs just as quickly as a normal system call might since : the added complexity of queueing and dequeueing the message just doesn't : happen. Plus it would be fairly easy to make the message-entry itself SMP-capable (i.e. allow several threads to attempt to sendmsg() the same message simultaniously, in which one succeeds and the other fails due to the message being in-progress. This would be useful for dispatching software interrupts). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message