[ECOS] [PATCH] Optimized mutex operations
Luoqi Chen
lchen@onetta.com
Thu Nov 1 23:40:00 GMT 2001
Robin,
Sorry for my late response to your questions, I didn't see your
message until today. The answer to your first question is lock_inner
does block as a mutex should. The loop at the beginning of function
only tries to set the MUTEX_WANT flag, most of the time it should
succeed on the first attempt, but we have to take care of potential
race conditions. Using cyg_atomic could be a little problematic, but
I am not sure what's the correct type I should use, I was hoping
someone would give me some advice on this.
-lq
> -----Original Message-----
> From: Robin Farine [mailto:acnrf@dial.eunet.ch]
> Sent: Wednesday, October 24, 2001 12:07 AM
> To: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] [PATCH] Optimized mutex operations
>
>
> "Luoqi Chen" <lchen@onetta.com> writes:
>
> > I've modified the current mutex implementation to take advantage of
> > atomic update
> > primitives provided in many processors, this should significantly
> > improve the
> > performance of operations on uncontested mutexi. The patch
> is available
> > at
> > http://www.freebsd.org/~luoqi/ecos .
> >
> > I've also discovered a race in the current mutex implementation's
> > priority
> > inheritance code: during unlock, the first thread blocking
> on the sleep
> > queue
> > is waken and inherits the priority of the previous owner.
> There lies a
> > window
> > between unlock returns and the new owner-to-be gets a
> chance to run in
> > which
> > another thread blocking on the same mutex might inherit a
> even higher
> > priority,
> > and when the owner-to-be becomes the owner, it has a lower
> priority than
> > one
> > of the threads blocked.
> >
> > -lq
>
> I see at least two problems with this implementation (but
> maybe I'm still
> sleeping so ...)
>
> 1. lock_inner() works like a spin-lock, not like a mutex.
> When a thread tries to
> acquire an already owned mutex, the thread that owns the
> mutex will not run
> until the next time-slice, thus the thread that polls the
> lock will keep the
> CPU, but uselessly.
>
> 2. volatile cyg_atomic locked; // owner and want flag bit
>
> cyg_atomic does not necessarily has the same memory layout
> as a pointer
>
>
> Hope this makes sense,
>
> Robin
>
More information about the Ecos-discuss
mailing list