I am trying to understand the how can synchronous event demultiplexing be a solution to busy waiting.
Suppose there are 3 IO operations and we have a code which is constantly looping to check if any of the 3 operation has data available to read.
arry = [event1 , event2 , event3]
while(arry is not empty)
{
for(i = 0 ; i <= 2 ; i++)
{
if(arry[i] has something to read)
{
read data;
}
else
{
continue to next i;
}
if(arry[i] read has finished){
remove i from arry
}
}
}
Above pseudo code does a busy waiting.
Now in synchronous event demultiplexing or to say reactor pattern an event listener is there to respond to an event as it occurs. But how can an event listener do that without busy waiting ?
The synchronous event demultiplexer or event notification interface as part of most modern operating systems is a native mechanism to effciently handle concurrent non-blocking resources.
Synchronous Event Demultiplexer. Uses an event loop to block on all resources. The demultiplexer sends the resource to the dispatcher when it is possible to start a synchronous operation on a resource without blocking (Example: a synchronous call to read() will block if there is no data to read.
Reactor Pattern is used to avoid the blocking of the Input/Output operations. It provides us with a handler that is associated with I/O operations.
A process is an instance (executing a task or a module) of a computer program that has been executed. Within a single process we can have multiple components called threads. You can visualize a thread like a to-do-list that has some number of instructions that need to be executed by the CPU of your computer. Think thread as a worker.
Imagine you have a 10 floor apartment. And you have a single worker with instructions and it has to knock each door to gather data from. In busy waiting , this poor worker, starting from first floor, will knock each door to check if data is ready to receive or not. It will do this up to the top floor. Then it will do the same process in his way down. This time it will skip the doors that it already received data before. So it will keep running up and down till it receives data from each door. This is basically what busy waiting is.
As you can see, with single thread, we can handle different resources without blocking. However this is not efficient, it will make the CPU consume a lot of memory and causes context switches which is extra hard work for the CPU. Also, a thread will waste most of its time for waiting, while it is waiting, the CPU will still be working.
Why is event demultiplexing a solution or more efficient?
Instead of all this heavy work, our single thread will not run up and down. It is not a worker anymore, it is a manager now and receives extra support by libuv library which uses the power of C++. Libuv will collect all the data with event demultiplexer, demultiplexer will include what data came from which door and what to do with this data, then it will pass the necessary data to event queue then event queue will pass the control to event loop. Now event loop's job is just to check if there is a waiting event, if there is, it will push it to the call stack which is where functions get executed.
event demultiplexer is called synchronous because, it does not knock 2 doors at the same time.
It is really hard to explain this complex subject in a simple way. I hope it helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With