[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more on light weight mutex
- Date: Wed, 4 Aug 1999 10:38:33 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: more on light weight mutex
Moving this back to the list.
On Wed, 4 Aug 1999, VALETTE Eric wrote:
> >>>>> "joel" == joel <joel at OARcorp.com> writes:
>
> joel> On Wed, 4 Aug 1999, VALETTE Eric wrote:
>
> joel> The thing that bothers me is that it introduces more CPU dependent code
> joel> and we have to provide that for all existing ports. If there is a way to
> joel> "use the generic" algorithm or simply write "mutexGet" as an inline with
> joel> an optional CPU depedenent macro as the first portion, then I am happy.
>
> Basically what is needed is either a
> test and set asm macro
> OR
> a lock exchange macros
> OR
> an atomic inc
>
> But I think this is no more than the interrupt_disable/enable code required...
I agree for a simple generic implementation for CPUs not providing a
better version.
The shared memory driver uses these test and set instructions so there are
assembly macros done there to do this type of work.
> Another issue with this kind of mutex implementation is that it does not
> provide any kind of priority inversion avoidance...
Agreed. This would unfortunately be a side-effect of using the very
light-weight mutex proposed.
The slightly heavier version I was proposing covers this situation.
A lot depends on how we view the use of these. Are these for simple
mutual exclusion for resources with relatively low contention -- thus few
conflicts and prioriry inversions. Or are these a theoretically correct
mutex that is just lighter than the BINARY_SEMAPHORE option on the Classic
Semaphores. Both approaches are valid, we just have to decide which way
to go.
I think the medium weight one is a nice first choice because we can give
each use of Classic semaphores exactly the semantics it currently has.
This minimizes the chances of breaking anything while saving overhead.
PLUS it is easy to implement. :)
I do like the idea of having a low level mutex as proposed. We just have
to decide how feature rich the blocking side is.
--joel