The run-time service of operating system

The story of the interleaved action between the applications and OS kernel is a template of event-driving acting. To the OS, everything is a event.  

Naturally, the operating system is designed as a suit of run-time service which should provides ideal real time service to the applications. However, when lots of applicants, any program that tries to invoke the same service of OS--the asynchronous disrupted input data of hardware and the asynchronous API calling of software, try to invoke the same limited service code and data, system functions and data structure and driver, the system needs to synchronize and sequence these callers. This process makes some applicants wait and blocked, lowering the efficiency of the app even ignoring the critical inputting data. In terms of Interleaving between OS and applications, the application has to wait for the returned information of the service, blocked or unblocked. 

In short, the overloaded service invoked by the applications make the inner synchronization of the run-time OS, and this also leads the waiting of applications. 

To the OS, every input, the invoking of API or driver, is asynchronous event-- the OS would never wait any input and invoking. To the applications, the returning of OS service is asynchronous, because the inner synchronization of OS, apps never know when the service would return the result which the app must get and use. So, most of the time, apps have to wait for the returning and knowing the state of service(if OS would not provide the real asynchronous IO), this leads the synchronization of apps for the OS. 

All of these make the work of implementing of inner synchronization of OS critical and fundamental.