>It's actually not the best, because when it returns "did not match" >you have to loop and try again.
Not sure what else you would do? The purpose of a spin lock is to avoid a more expensive kernel call if the mutex is released quickly (or not taken at all). Presumably you enter the kernel after n tries and sleep so that you are not using up quanta while spinning. >The amount of looping depends on >contention level. The real secret is to reduce the time spent holding the mutex in general. As for priority inversion (where a lower priority task gets to execute because is it holding a mutex that a higher priority thread is waiting on) that should be addressed in the kernel. The lower priority thread should get temporary priority elevation. On Tue, Aug 11, 2009 at 9:34 AM, Jamie Lokier <ja...@shareable.org> wrote: > Michael Schnell wrote: > > Jim Donelson wrote: > > > All that is really required is an atomic exchange. > > > Suppose 1 means taken, 0 means free. I do an exchange with a 1. If I > got > > > back a zero, it's mine. > > > > True with a Mutex, not true with a Futex. Here you need a second bit in > > user-space that tells the releaser that it is to wake up a sleeping > > waiter. Otherwise, any release would need a system call. > > Indeed. A atomic-swap instruction provides enough bits, but it's hard > to get the algorithm right. > > > Seemingly the best instruction to handle these bits is "atomic compare > > and exchange" (e.g. provided by the X86 CPU). > > It's actually not the best, because when it returns "did not match" > you have to loop and try again. The amount of looping depends on > contention level. Ideal would be an > atomic-do-what-I-need-for-my-algorithm operation. However, > atomic-compare-exchange can be used for everything, so it's a useful > instruction if you have to pick one. > > -- Jamie > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev >
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
