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."
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. :)
