One of the most common mistakes engineers make while writing multi-threaded programs is assuming common operations are thread-safe ⚡ I went through the assembly code to understand why exactly "count++" is not thread-safe and compiled my learnings into a super interesting and highly practical video that covers - how threads compete for the shared resource - how to disassemble code to instructions - how code actually gets executed on the CPU give it a watch: youtu.be/kBHd7kn_1EU ⚡ Admissions for my System Design August 2024 cohort are open, if you are SDE-2, SDE-3, and above and looking to build a rock-solid intuition to design any and every system, check out arpitbhayani.me/course #AsliEngineering #ConcurrencyInDepth
Arpit Bhayani bhaiya, I am studying these topics in 2nd year COA. Still not clear about the real world applications for learning assembly. Is it only to make our understanding better or still people code in assembly?
It becomes more interesting where count is of long data type, then it would take 2 bytes to store data. In case of data race ... it could happen that one byte got update and one byte is still to be updated and thread read the unconsistent data from it.
It is because of other threads can execute the instructions of count which can lead to race condition, correct me if I’m wrong
System Design for SDE-1s: https://arpitbhayani.me/sys-design System Design for SDE-2s and above: https://arpitbhayani.me/course Redis Internals: https://arpitbhayani.me/redis-internals My knowledge base: https://arpitbhayani.me/knowledge-base Bookshelf: https://arpitbhayani.me/bookshelf Research Papers: https://arpitbhayani.me/papershelf