From 81178d23442a334787e86c931b3de9129145b091 Mon Sep 17 00:00:00 2001 From: raghavbhartia Date: Wed, 21 Nov 2018 20:26:36 +0530 Subject: [PATCH] Added few advantages of event driven architecture (#22389) --- guide/english/computer-science/evented-servers/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guide/english/computer-science/evented-servers/index.md b/guide/english/computer-science/evented-servers/index.md index f3992018b4..c804d8fb79 100644 --- a/guide/english/computer-science/evented-servers/index.md +++ b/guide/english/computer-science/evented-servers/index.md @@ -11,7 +11,7 @@ We'll illustrate this with an example. Let's say you are the owner of a cab company (let it be known as the Server) and you have people calling your company (let them be known as Clients) that want to arrange a pickup (let those be known as Requests). You hire operators (let them be known as Processes/Threads) to take orders from the Clients. Your business logic states that your operator must stay on the line until a cab driver has been dispatched to the client. So essentially, you would want to hire as many operators as the amount of cab drivers that you can dispatch. -With an Evented server, there is only one operator that is able to take the pickup details from the customers, but knows to call the customer back once the cab driver has been dispatched to him. +With an Evented server, there is only one operator that is able to take the pickup details from the customers, but knows to call the customer back once the cab driver has been dispatched to him. One more advantage is that, because of a single thread, there are no race conditions. So, locking/unlocking is not required. Cpu utilization is also high since the thread does not have to wait. These kind of servers use callbacks to let the clients know when their requests have been dealt with.