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.
Awesome video! I'd like to add something: using finally to release the lock on the mutex. -- takeMVar mutex finally (putStrLn greeting) (putMVar mutex ()) --
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?
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Loving this series!
I am only half way through but I just wanted to say video is a great resource! Clear and concise!
Very clear explanations! Love it!
Thanks for these series, they are helping me a lot :) !
Wow, excellent lesson. Most concurrency gotchas in less than half an hour!
for some reason i find the "show tid" at 11:00 incredibly funny
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?
Awesome video!
I'd like to add something: using finally to release the lock on the mutex.
--
takeMVar mutex
finally (putStrLn greeting) (putMVar mutex ())
--
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!
Yeeaa... Finally more expert content.
Thank you and please keep it up
0
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"
Awesome!!! Thank you so much!!!
Concurrency with Mvar and channels reminds me of concurrency with C
[18:36] I think you can use `replicateM_`.
I would use replicateM in place of mapM
Very good
putStrLn mutex needs a bracket.