lkml.org 
[lkml]   [2002]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Fast Userspace Mutexes III.
Date
In message <20020307004821.A26624@twiddle.net> you write:
> On Thu, Mar 07, 2002 at 02:39:47PM +1100, Rusty Russell wrote:
> > But since the real problem here is "lock held forever", so I don't care.
>
> No, "lock held forever" merely makes the example trivial.
> "Lock held for a while" is the real problem.
>
> > > You really do need that cmpxchg loop.
> >
> > Well, not decrementing if count < 0 already also works
>
> How, exactly, are you planning on doing that atomically?
> Clue: 386 SMP requires an extra spinlock.

Fortuntely, it doesn't need to be atomic. This got me too, but Paul
Mackerras convinced me.

We don't care if someone decrements it between us checking < 0 and
doing the atomic_dec_and_test. So the only thing we worry about is
the "up" case. A userspace "up" will go into the kernel (since count
< 0), and the kernel "up" will wake us since we are on the queue
before we do this test.

> > PS. Will Alpha have to do any special magic with the mmap PROT_SEM flag?
>
> No.

Damn, I was hoping to find out which arch actually is going to use
this. I hate untested code.

Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.115 / U:1.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site