I've seen many videos in this series so far and have to congratulate you for the clear explanation style. I've heard about the STM paper before and think I'm now in a position to try to uderstand it. I'll like the refereces to the conceptual sources! Thank you.
Totally agree with you. Sadly, I don't have access to my usual setup right now and currently do the series on a 10 year old laptop which seems to cause problems when recording my screen. I'll look into fixing/improving it!
They are very similar. With a semaphore, you'd have waitForCounter wait on the semaphore n times, waking up for each addToResult. With STM, each retry knows the STM variables that have been accessed in that transaction were in a state that didn't let the transaction complete, so it can be suspended until they change. The semaphore just supports two transactions; increment, and decrement once not zero. This example replaced the latter with read sum once endCtr is n. The key advantage is that STM lets us write the logic, rather than worry about lock orders, matched semaphore step sizes, or how many threads are waiting for a broadcast, or whether every place accessing a variable has used the correct lock to do so.
I'm not a haskell expert (correct me if I'm wrong), but how I understand this, is that instead of mutating the result you're using a new one each time you're writing on it. Similar like IO () Monad generates a new World' from World, here STM Monad generates a new Result' from the previous Result. But I'm sure internally the compiler mutates the same shared memory.
@@luisenriquemunozmartin6690 no, this is not a new result. It is using the same result as the input and it is getting a different value. It is not pure.
@danconcep its not pure, you need sideefects to work with threads. In lesson 27 on Exceptions he suggests to use "Use Maybe and Either because they are purely functional" instead of exceptions he also says: "purely functional code has no idea what exception is" and "There are things that only execeptions can handle - IO, Threads, System, these things cant be solved only with Maybe and Either."
Result is a TVar, which is conditionally mutable. STM transactions run via atomically can alter it, but only atomically. atomically produces an IO action, and only the runtime can actually perform those, and that's where impure effects occur. Because STM actions run atomically, they cannot directly observe mutation. If mutation to their observed state occurs, they will retry or fail. The order they run, when started via threads with forkIO, is nondeterministic. As far as addToResult or waitForCounter are concerned, TVars are just like the State monad; one input, one output, like a pure function. Retry means some other input state must occur, and automatically builds a precondition to wait for before sum can be returned.
I've seen many videos in this series so far and have to congratulate you for the clear explanation style. I've heard about the STM paper before and think I'm now in a position to try to uderstand it. I'll like the refereces to the conceptual sources! Thank you.
Thanks for sharing all your wisdom!
Thank you very much. Another great explanation
great videos!
Very clear, thank you!
Good stuff. Please fix your mic! I like the content, but the constant mic glitches are annoying.
Totally agree with you. Sadly, I don't have access to my usual setup right now and currently do the series on a 10 year old laptop which seems to cause problems when recording my screen. I'll look into fixing/improving it!
@@philipphagenlocher Watching the video with 1.25 x or 1.5 x speed makes it slightly easier on the ears :)
@Everett Santana Flixportal :P
@Tobias Dean Thanks, I went there and it seems like a nice service =) Appreciate it!
@Everett Santana glad I could help :D
Hey! Very good vids, but as of now it's really hard to follow because of the horrible sound
So it's an infinite loop to check the end of threads ?
I think that Semaphores were better in that case, no?
They are very similar. With a semaphore, you'd have waitForCounter wait on the semaphore n times, waking up for each addToResult. With STM, each retry knows the STM variables that have been accessed in that transaction were in a state that didn't let the transaction complete, so it can be suspended until they change.
The semaphore just supports two transactions; increment, and decrement once not zero. This example replaced the latter with read sum once endCtr is n.
The key advantage is that STM lets us write the logic, rather than worry about lock orders, matched semaphore step sizes, or how many threads are waiting for a broadcast, or whether every place accessing a variable has used the correct lock to do so.
ily
I do not understand how this is pure. Is result mutable?
I'm not a haskell expert (correct me if I'm wrong), but how I understand this, is that instead of mutating the result you're using a new one each time you're writing on it. Similar like IO () Monad generates a new World' from World, here STM Monad generates a new Result' from the previous Result. But I'm sure internally the compiler mutates the same shared memory.
@@luisenriquemunozmartin6690 no, this is not a new result. It is using the same result as the input and it is getting a different value. It is not pure.
@danconcep its not pure, you need sideefects to work with threads. In lesson 27 on Exceptions he suggests to use "Use Maybe and Either because they are purely functional" instead of exceptions he also says: "purely functional code has no idea what exception is" and "There are things that only execeptions can handle - IO, Threads, System, these things cant be solved only with Maybe and Either."
Result is a TVar, which is conditionally mutable. STM transactions run via atomically can alter it, but only atomically.
atomically produces an IO action, and only the runtime can actually perform those, and that's where impure effects occur.
Because STM actions run atomically, they cannot directly observe mutation. If mutation to their observed state occurs, they will retry or fail. The order they run, when started via threads with forkIO, is nondeterministic.
As far as addToResult or waitForCounter are concerned, TVars are just like the State monad; one input, one output, like a pure function. Retry means some other input state must occur, and automatically builds a precondition to wait for before sum can be returned.