WebSVN – HelenOS-doc – Diff – /design/trunk/src/ch_ipc.xml

   <para>Due to the high intertask communication traffic, IPC becomes critical
   subsystem for microkernels, putting high demands on the speed, latency and
   reliability of IPC model and implementation. Although theoretically the use
   of asynchronous messaging system looks promising, it is not often
   implemented because of a problematic implementation of end user
-  applications. HelenOS implements a fully asynchronous messaging system with
+  applications. HelenOS implements fully asynchronous messaging system with a
-  a special layer providing a user application developer a reasonably
+  special layer providing a user application developer a reasonably
   synchronous multithreaded environment sufficient to develop complex
   protocols.</para>
   <section>
     <title>Services provided by kernel</title>
       <emphasis>manager</emphasis> task is found or a new one is created and
       control is transfered to this manager task. The manager tasks pops
       messages from the answerbox and puts them into appropriate queues of
       running tasks. If a task waiting for a message is not running, the
       control is transferred to it.</para>
       <figure float="1">
         <mediaobject id="ipc2">
           <imageobject role="pdf">
             <imagedata fileref="images/ipc2.pdf" format="PDF" />
           </imageobject>
         </mediaobject>
         <title>Single point of entry</title>
       </figure>
       <para>Very similar situation arises when a task decides to send a lot of
       messages and reaches kernel limit of asynchronous messages. In such
       situation 2 remedies are available - the userspace liberary can either
       cache the message locally and resend the message when some answers
       arrive, or it can block the thread and let it go on only after the
     </section>
     <section>
       <title>Ordering problem</title>
-      <para>Unfortunately, in the real world is is never so easy. E.g. if a
+      <para>Unfortunately, the real world is is never so simple. E.g. if a
-      server handles incoming requests and as a part of it's response sends
+      server handles incoming requests and as a part of its response sends
       asynchronous messages, it can be easily prempted and other thread may
       start intervening. This can happen even if the application utilizes only
 kernel thread. Classical synchronization using semaphores is not
-      possible, as locking on them would block the thread completely and the
+      possible, as locking on them would block the thread completely so that
-      answer couldn't be ever processed. The IPC framework allows a developer
+      the answer couldn't be ever processed. The IPC framework allows a
-      to specify, that the thread should not be preempted to any other thread
+      developer to specify, that part of the code should not be preempted by
-      (except notification handlers) while still being able to queue messages
+      any other thread (except notification handlers) while still being able
-      belonging to other threads and regain control when the answer
+      to queue messages belonging to other threads and regain control when the
-      arrives.</para>
+      answer arrives.</para>
       <para>This mechanism works transparently in multithreaded environment,
-      where classical locking mechanism (futexes) should be used. The IPC
+      where additional locking mechanism (futexes) should be used. The IPC
-      framework ensures that there will always be enough free threads to
+      framework ensures that there will always be enough free kernel threads
-      handle the threads requiring correct synchronization and allow the
+      to handle incoming answers and allow the application to run more
-      application to run more user-space threads inside the kernel threads
+      user-space threads inside the kernel threads without the danger of
-      without the danger of locking all kernel threads in futexes.</para>
+      locking all kernel threads in futexes.</para>
     </section>
     <section>
       <title>The interface</title>
+      <para>The interface was developed to be as simple to use as possible.
+      Classical applications simply send messages and occasionally wait for an
+      answer and check results. If the number of sent messages is higher than
+      kernel limit, the flow of application is stopped until some answers
+      arrive. On the other hand server applications are expected to work in a
-      <para></para>
+      multithreaded environment.</para>
+      <para>The server interface requires developer to specify a
+      <function>connection_thread</function> function. When new connection is
+      detected, a new userspace thread is automatically created and control is
+      transferred to this function. The code then decides whether to accept
+      the connection and creates a normal event loop. The userspace IPC
+      library ensures correct switching between several userspace threads
+      within the kernel environment.</para>
     </section>
   </section>
 </chapter>

Subversion Repositories HelenOS-doc

(root)/design/trunk/src/ch_ipc.xml – Rev 114 → 117