lkml.org 
[lkml]   [1999]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] i386 rw semaphore + use for mmap_sem
On Sun, 21 Nov 1999, Manfred Spraul wrote:

> 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/

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