Re:Sane Concurrency with Go
by rakoo on Wednesday March 12, 2014 @05:29PM
(#7388526)
Although more verbose, I find this pattern much better than mutexes.
The problem with mutexes is that they are some kind of cheap way for the developer to say "stop the world while I think", but they require you to be quite aware of what happens in an object, too much I think.
In this example you'd have a mutex for the Account, so each time you want to change the amount you need to lock and unlock it. That's trivial for an object like that, but it can quickly become complex: one mutex is not enough because it blocks the whole object, so you start having multiple mutexes. But then you don't remember which mutex blocks what so you must have some good documentation about that, but the documentation is not as well maintained as the rest so it starts rotting. And then your file spreads among so many lines you can't quite grasp all the ways parallelism can kill you.
In the given example, the mindset is different: _all_ methods called from the outside are non-modifying, they only stack the change to be made. The actual data manipulation is done in a very tight loop that does a very simple thing, and nothing outside of this loop ever deals with memory. As a developer, you can fit all the code that can be "dangerous" in a mere 7 lines of code, instead of having it spread among the file.
I concure it's a different mindset, quite different at that, but it's a pretty good one (ang go makes it very pleasant)
The problem with mutexes is that they are some kind of cheap way for the developer to say "stop the world while I think", but they require you to be quite aware of what happens in an object, too much I think.
In this example you'd have a mutex for the Account, so each time you want to change the amount you need to lock and unlock it. That's trivial for an object like that, but it can quickly become complex: one mutex is not enough because it blocks the whole object, so you start having multiple mutexes. But then you don't remember which mutex blocks what so you must have some good documentation about that, but the documentation is not as well maintained as the rest so it starts rotting. And then your file spreads among so many lines you can't quite grasp all the ways parallelism can kill you.
In the given example, the mindset is different: _all_ methods called from the outside are non-modifying, they only stack the change to be made. The actual data manipulation is done in a very tight loop that does a very simple thing, and nothing outside of this loop ever deals with memory. As a developer, you can fit all the code that can be "dangerous" in a mere 7 lines of code, instead of having it spread among the file.
I concure it's a different mindset, quite different at that, but it's a pretty good one (ang go makes it very pleasant)