Linux-insides: sequential locks in the Linux kernel
1–9 of 9 posts
Re: Linux-insides: sequential locks in the Linux kernel
#2Re: Linux-insides: sequential locks in the Linux kernel
#3[1] https://www.quora.com/What-is-difference-between-the-RCU-rea...
Re: Linux-insides: sequential locks in the Linux kernel
#4Where do these stand with respect to RCU locks? Are they a replacement, or are these used in different situations?
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.
Re: Linux-insides: sequential locks in the Linux kernel
#5[1] https://github.com/Amanieu/seqlock/blob/master/src/lib.rs
Re: Linux-insides: sequential locks in the Linux kernel
#6Not an expert but RCU is more complex with respect to checking the CPU states for activity to ensure consistency. Sequential locks use spinlocks and a counter and allows for concurrent reads. This link [1] actually answers it specifically (sorry about the quora link). [1] https://www.quora.com/What-is-difference-between-the-RCU-rea...
Re: Linux-insides: sequential locks in the Linux kernel
#7Readers using read_seqbegin() can still access the protected data.
Re: Linux-insides: sequential locks in the Linux kernel
#8Re: Linux-insides: sequential locks in the Linux kernel
#9On a related note, take a look a Hans Boehm's paper "Can Seqlocks Get Along With Programming Language Memory Models?" [1]. [1] http://www.hpl.hp.com/techreports/2012/HPL-2012-68.html
... in spite of my earlier claims in the previously
mentioned mailing list discussion.