> And I don't understand your "first" handing:
> > down_write_failed()
> > [...]
> > if (first) {
> > atomic_add(RWSEM_BIAS, &sem->count);
> > sem->writer = 0;
> > }
Okay, basically the first writer who comes along and has to wait is the
only one who is allowed to maintain the BIAS (otherwise when a reader does
a read_up, he won't see the result of zero indicating a wake up needs to
be done).
> I don't understand the atomic_add:
> a reader own the semaphore (sem->count=RWSEM_BIAS-1)
> a writer tries to get the lock:
> lock;subl RWSEM_BIAS,sem->count
> jnz failed <taken>
>
> within taken:
> first=1
> __up_write() not executed.
> schedule; (sem->count=-1)
This keeps sem->count < 0 which disallows new readers from obtaining the
lock (nescessary to prevent starvation).
> now up_read():
> lock;incl sem->count <now 0>
> jz wakeup <taken>
> --> wakeup the writer.
>
> the writer:
> if(first)
> atomic_add(RWSEM_BIAS,&sem->count);
>
> --> a writer is running, but sem->count is > 0.
Look at the assembler: on return from the __down_write_failed, it retries
the atomic sub. I suppose this can be rearranged to be put into
__down_write_failed so that on return it is always locked. I'm reworking
that part of it now (I'd warped my brain writing this! =), plus using it
for the rw spinlocks.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/