> From: Ola Liljedahl [mailto:ola.liljed...@arm.com] > Sent: Thursday, 31 March 2022 13.44 > > <snip> > >>> I think lock()/unlock() should be avoided in the read operation > >>> names, because no lock is taken during read. I like the critical > region > >>> begin()/end() names. > >> I was following the naming convention of rte_rwlock. Isn't the > seqlock > >> just a more scalable implementation of a reader/writer lock? > > > > I see your point. However, no lock is taken, so using lock()/unlock() > is somewhat misleading. > Conceptually, a reader lock is acquired and should be released. Now > there wouldn't be any negative effects of skipping the unlock operation > but then you wouldn't know if the data was properly read so you would > have to ignore any read data as well. Why even call > rte_seqlock_read_lock() in such a situation? > > In the only meaningful case, the lock is acquired, the protected data > is > read and the lock is released. The only difference compared to a more > vanilla lock implementation is that the release operation may fail and > the operation must restart.
Thank you for taking the time to correct me on this... I was stuck on the "lock" variable not being touched, but you are right: The serial number is a lock conceptually taken. Then I agree about the lock()/unlock() names for the read operation too. -Morten
