6 ms·
Mutex in Nodejs, ROTFL. This kind of bad programming leads to overuse of synchronization primitives. Nodejs is single threaded and doesnt need locks and mutexes
by piterrro 6y ago
Mutex in Nodejs, ROTFL.
This kind of bad programming leads to overuse of synchronization primitives.
Nodejs is single threaded and doesnt need locks and mutexes. In any application.
Properly writing code will make synchronization unnecessary. In the provided example, the saveBalance function should not overwrite the values of balance variable but rather increment its value (increment with negative too).
That's it your problem is solved, one line of code to change.
- aaomidi 6y agoRace conditions are in the nature of concurrent code. Not just parallel code. Take go, use gomaxprocs and set it to 1. Spawn a bunch of goroutines that share memory. And easily you'll have race conditions if you're not careful.
- piterrro 6y agoI didnt say race conditions are impossible in Nodejs. Just highlighted that good program engineering is enough to avoid it and programmers should do that in the first place.
- aaomidi 6y agoSure but at the same time there is a reason synchronization primitives exist. Readability of code > everything else.
- piterrro 6y agoNodejs doesn't have synchronization primitives, just because you use Promise and assign it to variable "mutex" doesn't make it any more real
- deleted 6y ago[deleted]
- dboreham 6y agoIt would be better if I had the time today to refute this in detail, because it's important that others reading this thread know this assertion is false, but...it's false.
- cphoover 6y agoAgreed Over the past 10 years, I've done async code to coordinate lots of different concurrent tasks in JS, never once needed a the use of a mutex.
- lostcolony 6y agoThat assumes that the underlying implementation of saveBalance can be updated to push the atomic operation downstream. In general you highlight the problem though; without the central datastore ensuring atomicity, this isn't really solving anything. I.e., if this app had multiple instances, you STILL have a problem, even with this solution, since nothing guarantees that another -instance- hasn't also loaded the old data.
- piterrro 6y agoExactly, the author at the end explains that his approach doesnt work when you're using cluster/pm2/worker because these are separate processess, that just makes me laugh again as the whole post is pointless.
- dboreham 6y agoThe (somewhat contrived) example is trying to model what happens when the state change is done with I/O (hence by definition asynchronous). Your idea to make the state changes idempotent is a good one, but not typically possible.
- piterrro 6y agoRead the post title once again: "Node.js race conditions", why mention I/O when the post is not about it?
- hrishi 6y agoYou're right that this example is better solved without mutexes, but it's good that the article is introducing the concept to NodeJS devs who may not be used to it. Heck, I used mutexes extensively for years in C code and even I didn't know they were an option. That said, mutexes are also not always wrong. Compare-and-swap is good, ensuring atomicity is good, but sometimes a mutex is what you need, especially if you're fixing legacy code with concurrency issues.