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