Concurrency is one of those computer science topics that, in theory, makes sense but somehow manages to be a little confusing in practice. In Concurrency 101: From a Beginner’s Point of View, Mrinal gives a straightforward and step-by-step discussion on how languages such as Python, JavaScript, and Go handle more than one thing simultaneously. My favorite was the way the author explained concurrency not as “doing multiple things at the same time,” but rather as making progress on more than one task without getting in each other’s way.
The article starts by explaining the distinction between concurrency and parallelism, a difference that is essential for authors of responsive programs to understand. Mrinal then discusses the mechanisms that support concurrency: processes, threads, and event loops. Each of these has trade-offs, processes are heavier weight but safer, threads are lighter weight with the risk of race conditions, and event loops (like JavaScript’s) rely on non-blocking operations to stay efficient.
There’s a large section on synchronization and how programmers prevent “chaos” when threads are reading and writing shared data. I liked the presentation of mutexes and semaphores. The chef example for describing deadlocks made it easy to see how two threads might be waiting for each other forever. Mrinal does discuss practical solutions such as lock ordering, timeouts, and try-locks, all patterns we’ve discussed in CS-343 when we’ve talked about safe concurrent design.
The post then moves to lock-free programming and message passing and explains how atomic operations and the Actor Model can eliminate many synchronization problems altogether. I liked how Mrinal mapped these concepts to real systems like Go’s concurrency model and Apache Spark’s distributed processes, and how scaling depends on understanding which workloads are benefitted by which model.
I picked this resource because concurrency has been one of the more daunting topics for me. Having the opportunity to read a post that was written from the perspective of another student made it that much more relatable. The analogies, along with real engineering explanations, bridged the gap between textbook theory and real implementation.
I took away from this blog to conceptualize concurrency as orderly cooperation between tasks rather than chaos waiting to happen. It opened my eyes to how careful design choices, like tidy lock ordering or message passing, can make programs more correct and speedier. In the coming times, I will apply these lessons when I am working on multithreaded assignments or any program that demands responsiveness, like my Android application that I made this summer which communicates with a Flask backend. Having the fundamentals of concurrency under my belt will allow me to write cleaner, safer, and more scalable code.
Resources: https://mrinalxdev.github.io/mrinalxblogs/blogs/concurrency.html
Maria Delia 