@maralorn@kosmikus im pretty sure that was to replicate the behaviour of the Java version, no? Edsko did talk about examining the size of the critical region being the original motivation behind the Java code.
Using an MVar is using a lock. while the MVar is taken, no other Thread can take it.
@mangoiv@kosmikus Using a var type which takes a lock makes sense. But MVar seems a bit unfiting, because it can be empty. I was wondering what the argument over atomicModifyIORef or using a TVar would be. It seems like MVar has the best ergonomics and concurrency behavior?
@maralorn atomicModifyIORef doesn’t seem to work very well here in particular, mind that we throw an exception in one of the branches. Tbh I think an MVar is the perfect fit here 😅
@maralorn oh, in my mind its a lock which also has a value, locking the MVar is taking it, unlocking it is putting it. Or, if you so wish, you can even do it in reverse.
As far as i understand what you normally call a lock is what we’d call an MVar ().
@mangoiv@maralorn Yes, I agree with this view. I don't think Maybe is the right analogy. The MVar being empty is not a case you have to explicitly deal with, it already has a behaviour attached to it (blocking). Regarding the missing entry in the square, isn't that just an IORef?
Yeah, It's kinda IORef but I thought that doesn't count because it has less concurrency guarantees.
But I think I get now why MVars are much more useful. I have even used TMVars myself as locks when the action I wanted to do with it contained effects.
@kosmikus awesome! We need more videos like this. I really liked it when Rae did it a few years ago, however, I think it had some issues wrt recognising that you do things differently in the different ecosystems.
@mangoiv I'm embarrassed to admit I might not have watched this one. Well, you can tell me later whether we are running into the same issues or manage to avoid them somehow, and why.
Add comment