On 11/12/10 12:16, Andrew Doran wrote:
On Fri, Nov 12, 2010 at 11:09:20AM +0000, Andrew Doran wrote:It was deliberate. rwlocks are only effective in situations where the codepath is heavyweight. So I felt while it is worthwhile optimising them if possible, an all out jihad is just not warranted (as it might be for mutexes). So I made the decision to make them rely on CAS so that the implementation is transparent, easier to prove and maintain etc.To take an example where we grab a rwlock around something that doesn't need to be heavyweight, see stat() -> VOP_STAT(). With a bit of sneaky re-engineering that wouldn't need to acquire real locks at all. Something like Linux's seqlock (poor name) would do great. So to my mind rwlocks in their current form are a sort of stop-gap and convenience thing.
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.
By reasoning that we should design for tomorrows hardware, we might as well design explicitly for x86_64, and let all other emulate that. But in the past, I believe NetBSD have tried to raise above such simple and naïve implementation designs and actually try to grab the meaning of the operation instead of an explicit implementation. That have belonged more in the field of Linux. I hope we don't go down that path...
Johnny