lkml.org 
[lkml]   [2009]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v7][RFC]: mutex: implement adaptive spinning



On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > In fact, you might not even need a process C: all you need is for B to be
> > on the same runqueue as A, and having enough load on the other CPU's that
> > A never gets migrated away. So "C" might be in user space.

You're right about not needing process C.

> >
> > I dunno. There are probably variations on the above.
>
> Ouch! I think you are on to something:
>
> for (;;) {
> struct thread_info *owner;
>
> old_val = atomic_cmpxchg(&lock->count, 1, 0);
> if (old_val == 1) {
> lock_acquired(&lock->dep_map, ip);
> mutex_set_owner(lock);
> return 0;
> }
>
> if (old_val < 0 && !list_empty(&lock->wait_list))
> break;
>
> /* See who owns it, and spin on him if anybody */
> owner = ACCESS_ONCE(lock->owner);
>
> The owner was preempted before assigning lock->owner (as you stated).

If it was the current process that preempted the owner and these are RT
tasks pinned to the same CPU and the owner is of lower priority than the
spinner, we have a deadlock!

Hmm, I do not think the need_sched here will even fix that :-/

-- Steve



\
 
 \ /
  Last update: 2009-01-08 19:17    [W:2.377 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site