Messages in this thread | | | Date | Mon, 22 Nov 1999 12:44:39 -0500 (EST) | From | "Benjamin C.R. LaHaise" <> | Subject | Re: [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/
| |