Further on this discussion, I would like to ask few more doubts and
give few suggestions.
Doubts:
- why are we keeping the copy of lock variable in local %eax register
of CPU before before calling assembly function "__read_lock_failed"
which goes into loop and _NOT_ updating it again in loop.
movl $rwl (%eax)
If there are two or more than two processes running on two or more
different CPUs, how the locking is done when each CPU in system have
local copy of lock in their respective %eax processors, as they are
not manupulating or checking the global rwl (read-write lock in
memory), how the changes of one CPU can be visible to others while
trying to hold a lock.
I think I am missing something or have a wrong understanding of
assembly code, please clarify.
Suggestion:
File : arch/i386/kernel/semaphore.c
__read_lock_failed:
lock ; incl (%eax)
1: cmpl $1,(%eax)
js 1b
lock ; decl (%eax)
js __read_lock_failed
ret
- if we look at assembly code of __read_lock_failed (shown above), you
will find that we are looping until the value of lock is not >= 1,
this means that as soon as the value of lock will become 1 we will
come out of loop and will try to hold the rw lock by decrementing the
'lock' element of rw lock, but should not we check with condition >=
2, that will make it more efficient.
My reasoning for this is that we should only come out of loop and try
to hold the lock when there is any space for reader to go in critical
region (CR). When there are maximum number of readers in CR, the lock
will have value 0x00000001 (that means 1), so at value 1 there is
nospace for more readers in CR and incoming readers should keep on
looping, as soon as the value is incremented by the outgoing reader
from CR, the value will become 2 and at this time the waiting reader
should try to get in CR, so I think the condition for looping should
be:
1: lock; cmpl $2, (%eax)
js 1b
Please give your comments on this.
-gd
On 4/26/05, K.R. Foley <kr@xxxxxxxxxx> wrote:
> Gaurav Dhiman wrote:
> > Thanks for your reply, it clears my doubt of keeping two locks, one
> > for read and one for write. As this info can be stored in one element
> > only, we dont need two.
> >
> >
> >>You're right, but in fact, the implementation has been so that both
> >>information are encoded inside a single integer. You don't really need
> >>two counters, but :
> >> - a counter of readers
> >
> >
> > why we need to keep a count of readers, does that matter ?
>
> Because you can't get a write lock while there are any readers.
>
> From this and the rest of your message, I am not sure you are getting
> how this works:
>
> readers and writers are mutually exclusive. While there are readers you
> can't get the write lock. While there is a writer, there are no readers.
>
> >
> >
> >> - a bit indicating whether a writer owns the lock or not
> >
> >
> >>So, in fact, one bit of the integer is reserved to "mark" the rwlock as
> >>owned by a writer or not. Have a look at include/asm-i386/rwlock.h, and
> >>particularly the definition of RW_LOCK_BIAS.
> >
> >
> > Can you let me know whats the significance of this flag, is this flag
> > used to mark the writer and other bits used for keeping a count of
> > reades.
>
> This is the value that is subtracted to get the write lock. It also
> happens to be the init/idle value of the lock. So, if subtracting
> RW_LOCK_BIAS from the lock value yields 0x00000000 then you have
> acquired the write lock.
>
> Since we are on the subject, read locks are also gotten by subtracting
> from the value of the lock and are represented by any number less than
> 0x01000000.
>
> >
> >
> >>Have a look at the implementation of __build_read_lock_const() and
> >>__build_write_lock_const() is the same file.
> >
> >
> > cud not understand this assembly code, where is the helper function
> > defined, it is calling ?
>
> helper is the name of the function (in this case the spin function) that
> is passed in like:
>
> __build_write_lock(rw, "__write_lock_failed");
>
> Which is in spinlock.h
>
> >
> >
> >>Sincerly,
> >>
> >>Thomas
> >>--
> >>Thomas Petazzoni
> >>thomas.petazzoni@xxxxxxxx
> >>
> >
> >
> > --
> >
> > --
> > Kernelnewbies: Help each other learn about the Linux kernel.
> > Archive: http://mail.nl.linux.org/kernelnewbies/
> > FAQ: http://kernelnewbies.org/faq/
> >
> >
>
> --
> kr
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
