On Thu Oct 16, 2025 at 12:54 PM CEST, Tvrtko Ursulin wrote: > On 16/10/2025 10:50, Danilo Krummrich wrote: >> On Thu Oct 16, 2025 at 10:42 AM CEST, Tvrtko Ursulin wrote: >>> Yes, I even said two replies ago I will add the lock. In fact, it is >>> write tearing which would be a problem on 32-bit architectures, not just >>> read tearing. >>> >>> But again, it is not a lockless algorithm and nowhere I am implementing >>> a new locking primitive. So as much as my attempt to keep it light >>> hearted with the warm and fuzzy feeling comment was a miss, I also think >>> the whole long writeups afterwards about dangers of implementing own >>> lockelss algorithms and performance were the same. >> >> I think what's confusing people is the following: >> >> entity->stats->vruntime; /* Unlocked read */ >> >> You indicate with your comment that you are accessing something the is >> protected >> by a lock intentionally without the lock being held. >> >> I think there's not much room for people to interpret this as something else >> than a lockless algorithm approach. >> >>> So lets move on, there is no argument here. >> >> Indeed, there is no argument. But, if you say something like: >> >> "I can add the _existing_ entity->stats lock around it just as well for those >> warm and fuzzy feelings." > > You quote a comment from earlier in the thread which I already > acknowledged was misplaced. > >> it may be read by people as if you don't agree that for correctness either a >> lock or an atomic is required. So, people might keep arguing regardless. > > In the message you reply to I wrote that unlocked read in fact isn't > safe on 32-bit architectures. > > So yeah, good catch, will fix. No need for long writeups about things > which I did not say like performance claims, or inventing new locking > primitives.
Please read my reply carefully, I tried explaining to you why people may have read it in this way and why it may caused them to write the replies you think are unnecessary.
