]> git.baikalelectronics.ru Git - kernel.git/commit
seqlock: add 'raw_seqcount_begin()' function
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 4 May 2012 22:13:54 +0000 (15:13 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 4 May 2012 22:13:54 +0000 (15:13 -0700)
commitb07ea4263e04c8cdca8ba356e842a7f1938fa099
tree9078ecf501ebeb4412a0f91ff3125f41fb2535ac
parentd69b87b481ffaf653ce5542130045fdc43e6a35a
seqlock: add 'raw_seqcount_begin()' function

The normal read_seqcount_begin() function will wait for any current
writers to exit their critical region by looping until the sequence
count is even.

That "wait for sequence count to stabilize" is the right thing to do if
the read-locker will just retry the whole operation on contention: no
point in doing a potentially expensive reader sequence if we know at the
beginning that we'll just end up re-doing it all.

HOWEVER.  Some users don't actually retry the operation, but instead
will abort and do the operation with proper locking.  So the sequence
count case may be the optimistic quick case, but in the presense of
writers you may want to do full locking in order to guarantee forward
progress.  The prime example of this would be the RCU name lookup.

And in that case, you may well be better off without the "retry early",
and are in a rush to instead get to the failure handling.  Thus this
"raw" interface that just returns the sequence number without testing it
- it just forces the low bit to zero so that read_seqcount_retry() will
always fail such a "active concurrent writer" scenario.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
include/linux/seqlock.h