Re:Linux-insides: sequential locks in the Linux kernel
by sriram_malhar on Sunday July 10, 2016 @11:43AM
(#12065944)
Where do these stand with respect to RCU locks? Are they a replacement, or are these used in different situations?
[ Parent
| on HN ]
Re:Linux-insides: sequential locks in the Linux kernel
by Amanieu on Sunday July 10, 2016 @01:15PM
(#12066274)
The main downside of seqlocks is that you usually can't have pointers in them. Since the basic scheme is read, do stuff, check if sequence counter changed, you need to make sure that you don't dereference a potentially invalid pointer in the "do stuff" phase if another thread is concurrently modifying the data.
RCU avoids this issue by essentially delaying freeing of objects until there are no longer any threads accessing it. But it requires very complicated mechanisms to track all active threads, whereas a seqlock is a very simple and self-contained.
In both cases the read-side overhead is tiny: for example on x86, you don't need any memory barrier or atomic instructions.