4f988f152e
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> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| crypto | ||
| drm | ||
| keys | ||
| linux | ||
| math-emu | ||
| media | ||
| misc | ||
| mtd | ||
| net | ||
| pcmcia | ||
| rdma | ||
| rxrpc | ||
| scsi | ||
| sound | ||
| target | ||
| trace | ||
| video | ||
| xen | ||
| Kbuild | ||