On 11/12/10 15:52, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 02:30:58PM +0100, Johnny Billquist wrote:
Hmm. The thing with rwlocks though is that the actual concept is
just that you have locks that you want to grab, with the expanded
idea that you can have them at two different levels. read or write.
There is nothing inherently CAS about that. On a VAX, I can easily
implement this with native instructions, but it will not be anything
near a CAS. But now, they are more or less forced to go via a CAS
anyway, for what I'd consider no good reason.
To re-iterate:
- The cheapest way to implement rwlocks on modern computers is with CAS.
Let me clarify that I have nothing against CAS, or the use of it to
implement rwlock, on machines that have CAS. I'm just arguing for not
assuming that we have CAS, and instead have the interface talk about the
actual operations we want to perform on the rwlock, and then let all
ports implement this in the way that makes sense on that architecture.
There is no real need to have the rwlock explicitly use CAS. CAS is an
implementation detail, and not the actual goal.
If something better than CAS comes along in a few years, we should be
able to use that too, without having to redesign the framework.
- rwlocks work badly in the real world. In applications where they do make
sense other primitives offer a better deal. For example Linux seqlocks
or distributed locks with a per-CPU component. Therefore it doesn't
make sense to spend time enhancing rwlocks.
You might have a point in that.
But I don't know if/when we'll get something else, nor exactly how that
will look like. I do know that the systems I'm observing have become
very sluggish, though.
Johnny
