From owner-freebsd-hackers Tue Aug 15 14:12:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id B535C37B7C5 for ; Tue, 15 Aug 2000 14:12:44 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id RAA39184; Tue, 15 Aug 2000 17:13:44 -0400 (EDT) (envelope-from dufault) From: Peter Dufault Message-Id: <200008152113.RAA39184@hda.hda.com> Subject: Re: IPC, shared memory, syncronization AND threads... In-Reply-To: from Ronald G Minnich at "Aug 15, 2000 01:07:57 pm" To: Ronald G Minnich Date: Tue, 15 Aug 2000 17:13:44 -0400 (EDT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 15 Aug 2000, Jonas Bulow wrote: > > > After doing some more thinking about the cmpxchgl-lock, it's quite hard > > to use it together with a technique involving the kernel. > > well, no I don't think it is. I used to use it a lot, see my earlier post > from today. One point to keep in mind is that you will get a big win from these approaches in low-contention situations. I've got something that I use in bus simulations. When a client process doesn't get the compare-and-swap lock in a few instructions it has to request it from a master process via a single master-request-FIFO which eventually answers it back through a per-client-response FIFO, continuing the blocked clients in the order that they missed the lock, and using up system calls and context switches to ensure that. Thus when I lose, I lose big time, but it gives me the ordering I want. When I win I wind up with no system calls. Sort of like a cache. If I was losing a lot I'd have to rethink the approach and use something to divy up the work properly. If ordering isn't required and you aren't worried about starvation, it simplifies things a lot because you can have a Linda-like pool of work requests to hand out to a swarm of worker bees. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message