RE: [ECOS] [PATCH] Optimized mutex operations

["Luoqi Chen" <lchen at onetta dot com>]

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
>