> 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 ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Fail-Safe systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
