Date: Tue, 15 Aug 2000 17:13:44 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: Ronald G Minnich <rminnich@lanl.gov> Cc: hackers@FreeBSD.ORG Subject: Re: IPC, shared memory, syncronization AND threads... Message-ID: <200008152113.RAA39184@hda.hda.com> In-Reply-To: <Pine.LNX.4.20.0008151307220.26668-100000@mini.acl.lanl.gov> from Ronald G Minnich at "Aug 15, 2000 01:07:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008152113.RAA39184>