On 2022-03-31 13:44, Ola Liljedahl wrote: > <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. > > <snip> > > - Ola
The RCU library also use the terms "lock" and "unlock" for the reader side.
