rwlocks revisited

[H. Peter Anvin]

Followup to:  <Pine.LNX.3.96.1000121214348.14221A-100000 en kanga.kvack.org>
By author:    "Benjamin C.R. LaHaise" <blah en kvack.org>
In newsgroup: linux.dev.kernel
>
> On Thu, 20 Jan 2000, David Howells wrote:
> 
> > I've just come across an i386 instruction I didn't realise existed (it's not
> > in my i386 assembly book), and while I hesitate to reopen the old rwlock
> > debate, I think its worth mentioning.
> > 
> > This instruction (or perhaps I should say intruction family) is
> > "cmpxchg*". I've known about a similar one on the m68k ("cas" & "cas2") for a
> > while. I was wondering why the writelock code was done using "subl" rather
> > than "cmpxchgl":
> 
> The reasons are as follows: I chose subl because it sets the condition
> codes in such a way as to determine which of 3 states the lock was in
> (unlocked, locked for reading but uncontended for writing and contended
> for writing), which is used to decide which action to take for rwsems. In
> addition, subl is faster than cmpxchgl for the typically uncontended case.
> 

There are a number of read-modify-write instructions on x86, and most
of them can be used this way.

   -hpa
-- 
<hpa en transmeta.com> at work, <hpa en zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/