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.
Regards,
Tvrtko
