Cleaning house for Diwali festival can help you write better multithreading programs

Diwali is one of my fav festivals. But before diwali comes cleaning. Imagine your mom gave you, your sibling and your father a task of cleaning house and putting stuff in attic. Challenge is only one person can stand/use that attic at a time. You all want to get this work done ASAP. One approach to do this is you, your sibling and your father — all of you work in parallel and dump stuff in attic. Careful reader might have recognised that there is possibility that you and your sibling can arrive near attic at same time with stuff to dump in attic but unfortunately attic can hold only one person so either of you have to wait — your sibling is elder than you hence he/she goes first(LOL) and you are waiting for your chance to dump stuff in attic. So little time is lost here on waiting for chance.

However your father sees a table near attic. So he comes with a strategy — he says he ll be in attic all time , you and your sibling will bring stuff and place it on table and go back to grap new stuff. Meantime your father ll grap stuff from table and put it in attic. If we understand this strategy clearly — we can say that even if you and your sibling come at same time near attic, you guys ll put your stuff on table nearby and leave to bring more and your father can take care of putting stuff in attic. so no time is wasted in waiting here.

You might ask me — sumit, how is this related to multithreading and all?

Classic multithreading situation: Resource which is commonly shared between threads has to be locked so that only one thread can access it. Similarly in our above example — attic was that resource while one person was there, others had to wait for their chance. but in 2nd strategy we saw — you, your sibling and your father were communicating with each other using that table and getting work done. If there was an item on table, your father knew, he had to put it in attic & you guys knew that stuffs need to be placed on table instead of attic.

There is famous quote in GO programming language documentation

Do not communicate by sharing memory; instead, share memory by communicating.

This is what we exactly did.

Let me take a technical simple example. You have to write a program that spwans N threads that increment a variable and in the end program needs to give total count of that variable.

eg: If three threads are spawned,three times a variable will be incremented and final total will be 3.

Classic approach will be locking that shared variable and incrementing it. This will give us correct count but we have to do locking and threads will need to wait if they come at same time to increment that variable.

I recently started learning Rust programming language and It has concept of channel. This channel has transmitter and receiver. Transmitter can put value in channel and receiver can retrieve that value. Careful reader might have understood table in our generic example was channel actually. You and your sibling were transmitters and your father was receiver. Technical term here would be multiple producers and single consumer.

I am not going to explain the rust code here( out of scope for this article) but I will explain what is happening. Basically program is spawning threads, creating multiple transmitters and sending value over channel and single receiver is listening on it and incrementing the value of the counter(variable).

This way multiple threads can communicate and get work done minimum locking resource.

Happy Learning 😃