Michael Schnell wrote:
> Jamie Lokier wrote:
> > That's right. It's possible to use atomic_compare_and_exchange for
> > unlock; it's correct. But you get that extra bit of spinning with SMP,
> > so atomic_dec is better.
>
> In fact I don't see why Ulrich did the unlock code like this:
>
> if (atomic_dec(val) != 1 ) {
> val = 0;
> futex_wake(&val, 1);
> };
>
>
>
> My current implementation is
>
> c = atomic_xchg(val, 0) {
> if (c=2) { // we own the lock, so
> // val can be either of 1 or 2
> futex_wake(&val, 1);
> };
Second implementation:
Thread 1 Thread 2 Thread 3
-------- -------- --------
[owns the lock] [running] [waiting]
c = atomic_xchg(val, 0);
[c == 2]
if (compare_swap(val, 0, 1))
return;
[owns the lock]
futex_wake(&val, 1);
[wakes Thread 3] [woken by Thread 1]
if (compare_swap(val,
0, 1))
[no]
compare_sawp(val, 1,
2))
[waiting]
In Ulrich's version Thread 2 sleeps and Thread 3 runs, which is about
the same cost. Keeping Thread 2 running is probably better for
average throughput.
But Ulrich's version is fairer, and does not allow starvation.
In your version Thread 3 can be starved by threads which are already
running, and that can happen repeatedly so it never runs. In Ulrich's
version, all threads are guaranteed to run because there's a FIFO
queue on the futex, modified only by desired scheduling policies.
-- Jamie
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
