>> [IN] looks strange. If this field modified after creation it is >> mutable. There are cases when such field could modified only once, >> but it still is atomic.
It is mistype. I mean "..could modified only once, but it still is mutable" > On 8 Dec 2021, at 08:56, Visa Hankala <v...@hankala.org> wrote: > > On Wed, Dec 08, 2021 at 02:41:47AM +0300, Vitaliy Makkoveev wrote: >> [IN] looks strange. If this field modified after creation it is >> mutable. There are cases when such field could modified only once, >> but it still is atomic. >> >> We have cases where we do assignment only once, like `unp_addr’ >> when we bind(2)ing socket and we don’t modify if until socket’s >> destruction. Since we could connect to successfully bind(2)ed >> socket only we could say within unp_connect() that `unp_addr’ >> could be accessed without lock. >> >> We also have the case where we could bind(2) already connected >> socket. I such case we could say `unp_addr’ is atomic because >> this is the pointer assignment which points to read-only data >> and this data immutable until socket’s destruction. >> >> But `unp_addr’ is still mutable. > > Please stop saying that a thing is simply "atomic". > > If one sees "atomic" in a locking annotation, one has no idea what > exactly it means. Nearly everything in the kernel can be seen as > "atomic" by choosing a suitable story. > > Whenever a piece of code accesses shared data without locking, there > has to be a well-defined protocol for the accesses. Otherwise the code > cannot function reliably. > > Locking annotations should at least hint toward the protocol. > Annotation "immutable after creation" or "immutable after setting" > are clearly better than just "atomic". >
