Subversion Repositories HelenOS-doc

Rev

Rev 85 | Rev 112 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed

Rev 85 Rev 99
Line 19... Line 19...
19 
 
 19 
 
20 
    <para>Every message consists of 4 numeric arguments (32-bit and 64-bit on
 20 
    <para>Every message consists of 4 numeric arguments (32-bit and 64-bit on
21 
    the corresponding platforms), from which the first one is considered a
 21 
    the corresponding platforms), from which the first one is considered a
22 
    method number on message receipt and a return value on answer receipt. The
 22 
    method number on message receipt and a return value on answer receipt. The
23 
    received message contains identification of the incoming connection, so
 23 
    received message contains identification of the incoming connection, so
24 
    that it can distinguish the messages between different senders. Internally
 24 
    that the receiving application can distinguish the messages between
25 
    the message contains pointer to the originating task and to the source of
 25 
    different senders. Internally the message contains pointer to the
26 
    the communication channel. If the message is forwarded, the originating
 26 
    originating task and to the source of the communication channel. If the
27 
    task identifies the recipient of the answer, the source channel identifies
 27 
    message is forwarded, the originating task identifies the recipient of the
28 
    connection in case of a hangup message.</para>
 28 
    answer, the source channel identifies the connection in case of a hangup
- 
 
 29 
    response.</para>
29 
 
 30 
 
30 
    <para>Every message must be eventually answered. The system keeps track of
 31 
    <para>Every message must be eventually answered. The system keeps track of
31 
    all messages, so that it can answer them with appropriate error code
 32 
    all messages, so that it can answer them with appropriate error code
32 
    should one of the connection parties fail unexpectedly. To limit buffering
 33 
    should one of the connection parties fail unexpectedly. To limit buffering
33 
    of messages in the kernel, every process is limited in a number of
 34 
    of the messages in the kernel, every process is has a limited account of
34 
    asynchronous messages it may have unanswered simultanously. If the limit
 35 
    asynchronous messages it can send simultanously. If the limit is reached,
35 
    is reached, the kernel refuses to send any other message, until some of
 36 
    the kernel refuses to send any other message, until some active message is
- 
 
 37 
    answered.</para>
- 
 
 38 
 
- 
 
 39 
    <para>To facilitate kernel-to-user communication, the IPC subsystem
- 
 
 40 
    provides notification messages. The applications can subscribe to a
- 
 
 41 
    notification channel and receive messages directed to this channel. Such
- 
 
 42 
    messages can be freely sent even from interrupt context as they are
- 
 
 43 
    primarily destined to deliver IRQ events to userspace device drivers.
- 
 
 44 
    These messages need not be answered, there is no party that could receive
36 
    the active messages are answered.</para>
 45 
    such response.</para>
37 
 
 46 
 
38 
    <section>
 47 
    <section>
39 
      <title>Low level IPC</title>
 48 
      <title>Low level IPC</title>
40 
 
 49 
 
41 
      <para>The whole IPC subsystem consists of one-way communication
 50 
      <para>The whole IPC subsystem consists of one-way communication
Line 45... Line 54...
45 
      messages. Every sent message is identified by a unique number, so that
 54 
      messages. Every sent message is identified by a unique number, so that
46 
      the response can be later matched against it. The message is sent over
 55 
      the response can be later matched against it. The message is sent over
47 
      the phone to the target answerbox. Server application periodically
 56 
      the phone to the target answerbox. Server application periodically
48 
      checks the answerbox and pulls messages from several queues associated
 57 
      checks the answerbox and pulls messages from several queues associated
49 
      with it. After completing the requested action, server sends a reply
 58 
      with it. After completing the requested action, server sends a reply
50 
      back to the answerbox of the originating task. </para>
 59 
      back to the answerbox of the originating task. If a need arises, it is
- 
 
 60 
      possible to <emphasis>forward</emphasis> a recevied message throught any
- 
 
 61 
      of the open phones to another task. This mechanism is used e.g. for
- 
 
 62 
      opening new connections.</para>
51 
 
 63 
 
- 
 
 64 
      <para>The arguments contained in the message are completely arbitrary
- 
 
 65 
      and decided by the user. The low level part of kernel IPC fills in
- 
 
 66 
      appropriate error codes if there is an error during communication. It is
- 
 
 67 
      ensured that the applications are correctly notified about communication
- 
 
 68 
      state. If the outgoing connection is closed with the hangup message, the
- 
 
 69 
      target answerbox receives a hangup message. The connection
- 
 
 70 
      identification is not reused, until the hangup message is acknowledged
- 
 
 71 
      and all other pending messages are answered.</para>
- 
 
 72 
 
52 
      <para>If a need arises, it is possible to <emphasis>forward</emphasis> a
 73 
      <para>If the server side decides to hangup an incoming connection, it
- 
 
 74 
      does it by responding to any incoming message with an EHANGUP error
- 
 
 75 
      code. The connection is then immediately closed. The client connection
- 
 
 76 
      identification (phone id) is not reused, until the client issues hangup
- 
 
 77 
      system call to close the outgoing connection.</para>
- 
 
 78 
 
- 
 
 79 
      <para>When a task dies (whether voluntarily or by being killes), cleanup
53 
      recevied message throught any of the open phones to another task. This
 80 
      process is started which performs following tasks.</para>
- 
 
 81 
 
- 
 
 82 
      <orderedlist>
- 
 
 83 
        <listitem>
- 
 
 84 
          <para>Hangs up all outgoing connections and sends hangup messages to
- 
 
 85 
          all target answerboxes.</para>
- 
 
 86 
        </listitem>
- 
 
 87 
 
- 
 
 88 
        <listitem>
54 
      mechanism is used e.g. for opening new connections.</para>
 89 
          <para>Disconnects all incoming connections.</para>
- 
 
 90 
        </listitem>
- 
 
 91 
 
- 
 
 92 
        <listitem>
- 
 
 93 
          <para>Disconnects from all notification channels.</para>
- 
 
 94 
        </listitem>
- 
 
 95 
 
- 
 
 96 
        <listitem>
- 
 
 97 
          <para>Answers all unanswered messages from answerbox queues with
- 
 
 98 
          appropriate error code.</para>
- 
 
 99 
        </listitem>
- 
 
 100 
 
- 
 
 101 
        <listitem>
- 
 
 102 
          <para>Waits until all outgoing messages are answered and all
- 
 
 103 
          remaining answerbox queues are empty.</para>
- 
 
 104 
        </listitem>
- 
 
 105 
      </orderedlist>
55 
    </section>
 106 
    </section>
56 
 
 107 
 
57 
    <section>
 108 
    <section>
58 
      <title>Services for user application</title>
 109 
      <title>System call IPC layer</title>
59 
 
 110 
 
60 
      <para>On top of this simple protocol the kernel provides special
 111 
      <para>On top of this simple protocol the kernel provides special
61 
      services including opening new connection to other tasks, offering
 112 
      services closely related to the inter-process communication. A range of
- 
 
 113 
      method numbers is allocated and protocol is defined for these functions.
- 
 
 114 
      The messages are interpreted by the kernel layer and appropriate actions
- 
 
 115 
      are taken depending on the parameters of message and answer. </para>
- 
 
 116 
 
- 
 
 117 
      <para>The kernel provides the following services:</para>
- 
 
 118 
 
- 
 
 119 
      <itemizedlist>
- 
 
 120 
        <listitem>
- 
 
 121 
          <para>Creating new outgoing connection</para>
- 
 
 122 
        </listitem>
- 
 
 123 
 
- 
 
 124 
        <listitem>
- 
 
 125 
          <para>Creating a callback connection</para>
- 
 
 126 
        </listitem>
- 
 
 127 
 
- 
 
 128 
        <listitem>
62 
      callback connections and sending and receiving address space areas.
 129 
          <para>Sending an address space area</para>
- 
 
 130 
        </listitem>
- 
 
 131 
 
- 
 
 132 
        <listitem>
- 
 
 133 
          <para>Asking for an address space area</para>
63 
      </para>
 134 
        </listitem>
- 
 
 135 
      </itemizedlist>
64 
    </section>
 136 
    </section>
65 
  </section>
 137 
  </section>
66 
 
 138 
 
67 
  <section>
 139 
  <section>
68 
    <title>Userspace view</title>
 140 
    <title>Userspace view</title>
Line 70... Line 142...
70 
    <para>The conventional design of the asynchronous api seems to produce
 142 
    <para>The conventional design of the asynchronous api seems to produce
71 
    applications with one event loop and several big switch statements.
 143 
    applications with one event loop and several big switch statements.
72 
    However, by intensive utilization of user-space threads, it was possible
 144 
    However, by intensive utilization of user-space threads, it was possible
73 
    to create an environment that is not necesarilly restricted to this type
 145 
    to create an environment that is not necesarilly restricted to this type
74 
    of event-driven programming and allows for more fluent expression of
 146 
    of event-driven programming and allows for more fluent expression of
75 
    application programs. </para>
 147 
    application programs.</para>
76 
 
 148 
 
77 
    <section>
 149 
    <section>
78 
      <title>Single point of entry</title>
 150 
      <title>Single point of entry</title>
79 
 
 151 
 
80 
      <para>Each tasks is associated with only one answerbox. If a
 152 
      <para>Each tasks is associated with only one answerbox. If a
Line 85... Line 157...
85 
      thread needs to wait for a message answer, an idle
 157 
      thread needs to wait for a message answer, an idle
86 
      <emphasis>manager</emphasis> task is found or a new one is created and
 158 
      <emphasis>manager</emphasis> task is found or a new one is created and
87 
      control is transfered to this manager task. The manager tasks pops
 159 
      control is transfered to this manager task. The manager tasks pops
88 
      messages from the answerbox and puts them into appropriate queues of
 160 
      messages from the answerbox and puts them into appropriate queues of
89 
      running tasks. If a task waiting for a message is not running, the
 161 
      running tasks. If a task waiting for a message is not running, the
90 
      control is transferred to it. </para>
 162 
      control is transferred to it.</para>
91 
 
 163 
 
92 
      <para>Very similar situation arises when a task decides to send a lot of
 164 
      <para>Very similar situation arises when a task decides to send a lot of
93 
      messages and reaches kernel limit of asynchronous messages. In such
 165 
      messages and reaches kernel limit of asynchronous messages. In such
94 
      situation 2 remedies are available - the userspace liberary can either
 166 
      situation 2 remedies are available - the userspace liberary can either
95 
      cache the message locally and resend the message when some answers
 167 
      cache the message locally and resend the message when some answers
Line 122... Line 194...
122 
      1 kernel thread. Classical synchronization using semaphores is not
 194 
      1 kernel thread. Classical synchronization using semaphores is not
123 
      possible, as locking on them would block the thread completely and the
 195 
      possible, as locking on them would block the thread completely and the
124 
      answer couldn't be ever processed. The IPC framework allows a developer
 196 
      answer couldn't be ever processed. The IPC framework allows a developer
125 
      to specify, that the thread should not be preempted to any other thread
 197 
      to specify, that the thread should not be preempted to any other thread
126 
      (except notification handlers) while still being able to queue messages
 198 
      (except notification handlers) while still being able to queue messages
127 
      belonging to other threads and regain control when the answer arrives.
 199 
      belonging to other threads and regain control when the answer
128 
      </para>
 200 
      arrives.</para>
129 
 
 201 
 
130 
      <para>This mechanism works transparently in multithreaded environment,
 202 
      <para>This mechanism works transparently in multithreaded environment,
131 
      where classical locking mechanism (futexes) should be used. The IPC
 203 
      where classical locking mechanism (futexes) should be used. The IPC
132 
      framework ensures that there will always be enough free threads to
 204 
      framework ensures that there will always be enough free threads to
133 
      handle the threads requiring correct synchronization and allow the
 205 
      handle the threads requiring correct synchronization and allow the