this post was submitted on 04 Jul 2025
184 points (98.9% liked)
Programming
21381 readers
209 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Exactly what I see at work. I have a 'senior' C++ team lead which I have to explain over and over that for concurrent access of variables in device drivers one needs meticulous locking of shared variables. He was helding the view that when one thread is modifying a variable and another one is only reading it, then it's no race condition - even if the code crashes. And he still responds with generated code and suggesting names of members that don't exist.
This would infuriate me to no end. It's literally the definition of a data race. All data between threads needs to either be accessed through synchronization primitives (mutexes, atomic access, etc) or needs to be immutable. For the most part, this should include fds, though concurrent writes to stderr might be less of an issue (still a good idea to lock/buffer it and stdout though to avoid garbled output).
It's been so long since I've had to worry about this type of race condition, and like you...it infuriates me reading that comment.
Exactly.