On 02/19/2013 04:12 PM, David Laight wrote: >> I wouldn't go that far... ;-) Unfairness is not a show-stopper right? >> IMHO, the warning/documentation should suffice for anybody wanting to >> try out this locking scheme for other use-cases. > > I presume that by 'fairness' you mean 'write preference'? > Yep. > I'd not sure how difficult it would be, but maybe have two functions > for acquiring the lock for read, one blocks if there is a writer > waiting, the other doesn't. > > That way you can change the individual call sites separately. > Right, we could probably use that method to change the call sites in multiple stages, in the future. > The other place I can imagine a per-cpu rwlock being used > is to allow a driver to disable 'sleep' or software controlled > hardware removal while it performs a sequence of operations. > BTW, per-cpu rwlocks use spinlocks underneath, so they can be used only in atomic contexts (you can't sleep holding this lock). So that would probably make it less attractive or useless to "heavy-weight" usecases like the latter one you mentioned. They probably need to use per-cpu rw-semaphore or some such, which allows sleeping. I'm not very certain of the exact usecases you are talking about, but I just wanted to point out that percpu-rwlocks might not be applicable to many scenarios. ..(which might be a good thing, considering its unfair property today). Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
