Comment by hinkley
3 hours ago
I think it says if your async code holds locks you’re gonna have a bad time. Async and optimistic locks probably should go hand in hand.
I would think finalizers and async code magnify problems that are already there.
3 hours ago
I think it says if your async code holds locks you’re gonna have a bad time. Async and optimistic locks probably should go hand in hand.
I would think finalizers and async code magnify problems that are already there.
If you use a single-threaded executor then you don't need locks in your async code. Well, you might use external locks, but not thread synchronization primitives.
When I write async code I use a single-threaded multi-process pattern. Look ma'! No locks!
Well, that's not very fair. The best async code I've written was embarrassingly parallel, no-sync-needed, read-only stuff. If I was writing an RDBMS I would very much need locks, even if using the single-threaded/multi-processed pattern. But also then my finalizers would mainly drop locks rather than acquire them.
that isn’t the panacea you describe it to be. you just happen to write a lot of code where writing it that way doesn’t result in consistency problems.
You do have to be careful that all of your data updates are transitive, or you have to hold all of the updates until you can apply them in sequential order. One of my favorite tricks there is to use a throttling or limiting library, start all of the tasks, and then run a for loop to await each answer in order. You still have front-of-line issues but you can make as much forward progress as can be made.