RE: [ECOS] [PATCH] Optimized mutex operations

RE: [ECOS] [PATCH] Optimized mutex operations

[Luoqi Chen]

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
> 

Re: [ECOS] [PATCH] Optimized mutex operations

[Robin Farine]

"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

[ECOS] [PATCH] Optimized mutex operations

[Luoqi Chen]

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