Awesome video! I'd like to add something: using finally to release the lock on the mutex. -- takeMVar mutex finally (putStrLn greeting) (putMVar mutex ()) --
This video is very helpful and well explained. They demonstrate possible problems you might encounter pretty well, make sure to use STM though for real life multithreading purposes.
A few remarks: The examples shown are not the prettiest (no exception handling with threads is never a good idea!) and using MVar and Chan for purposes of synchronization is not good practice! There are other datatypes (QSem, QSemN) for this purpose. MVar and Chan are generally not safe and multithreaded code should use Software Transactional Memory which we will look at in another video. System.IO functions are automatically multiplexed when using lightweight threads (spawned by forkIO) but as we have seen: That does not always work! ;)
Another way to use the mutex would be to start with an empty MVar. A thread would try to store its token in it and would have to wait for the MVar to be empty (again). This approach would also allow to store some information about the locking thread in the lock token. Btw. is there a command to "peek" into an MVar, i.e. for reading w/o removing the value from the MVar?
I am only half way through but I just wanted to say video is a great resource! Clear and concise!
Loving this series!
Very clear explanations! Love it!
Thanks for these series, they are helping me a lot :) !
for some reason i find the "show tid" at 11:00 incredibly funny
Yeeaa... Finally more expert content.
Thank you and please keep it up
0
Wow, excellent lesson. Most concurrency gotchas in less than half an hour!
Awesome video!
I'd like to add something: using finally to release the lock on the mutex.
--
takeMVar mutex
finally (putStrLn greeting) (putMVar mutex ())
--
This video is very helpful and well explained. They demonstrate possible problems you might encounter pretty well, make sure to use STM though for real life multithreading purposes.
What's wrong with using MVars and Channels in "real life" code?
A few remarks: The examples shown are not the prettiest (no exception handling with threads is never a good idea!) and using MVar and Chan for purposes of synchronization is not good practice! There are other datatypes (QSem, QSemN) for this purpose. MVar and Chan are generally not safe and multithreaded code should use Software Transactional Memory which we will look at in another video. System.IO functions are automatically multiplexed when using lightweight threads (spawned by forkIO) but as we have seen: That does not always work! ;)
Thanks for the series!
Awesome!!! Thank you so much!!!
Concurrency with Mvar and channels reminds me of concurrency with C
Another way to use the mutex would be to start with an empty MVar. A thread would try to store its token in it and would have to wait for the MVar to be empty (again). This approach would also allow to store some information about the locking thread in the lock token. Btw. is there a command to "peek" into an MVar, i.e. for reading w/o removing the value from the MVar?
Take a look at "withMVar"
Very good
I would use replicateM in place of mapM
putStrLn mutex needs a bracket.
[18:36] I think you can use `replicateM_`.