Subversion Repositories HelenOS-doc

Rev

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

Rev 99 Rev 112
Line 7... Line 7...
7 
  <para>Due to the high intertask communication traffic, IPC becomes critical
 7 
  <para>Due to the high intertask communication traffic, IPC becomes critical
8 
  subsystem for microkernels, putting high demands on the speed, latency and
 8 
  subsystem for microkernels, putting high demands on the speed, latency and
9 
  reliability of IPC model and implementation. Although theoretically the use
 9 
  reliability of IPC model and implementation. Although theoretically the use
10 
  of asynchronous messaging system looks promising, it is not often
 10 
  of asynchronous messaging system looks promising, it is not often
11 
  implemented because of a problematic implementation of end user
 11 
  implemented because of a problematic implementation of end user
12 
  applications. HelenOS implements a fully asynchronous messaging system but
 12 
  applications. HelenOS implements a fully asynchronous messaging system with
13 
  with a special layer providing a user application developer a reasonably
 13 
  a special layer providing a user application developer a reasonably
14 
  synchronous multithreaded environment sufficient to develop complex
 14 
  synchronous multithreaded environment sufficient to develop complex
15 
  protocols.</para>
 15 
  protocols.</para>
16 
 
 16 
 
17 
  <section>
 17 
  <section>
18 
    <title>Services provided by kernel</title>
 18 
    <title>Services provided by kernel</title>
Line 47... Line 47...
47 
    <section>
 47 
    <section>
48 
      <title>Low level IPC</title>
 48 
      <title>Low level IPC</title>
49 
 
 49 
 
50 
      <para>The whole IPC subsystem consists of one-way communication
 50 
      <para>The whole IPC subsystem consists of one-way communication
51 
      channels. Each task has one associated message queue (answerbox). The
 51 
      channels. Each task has one associated message queue (answerbox). The
52 
      task can open connections (identified by phone id) to other tasks, send
 52 
      task can call other tasks and connect it's phones to their answerboxes.,
53 
      and forward messages through these connections and answer received
 53 
      send and forward messages through these connections and answer received
54 
      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
55 
      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
56 
      the phone to the target answerbox. Server application periodically
 56 
      the phone to the target answerbox. Server application periodically
57 
      checks the answerbox and pulls messages from several queues associated
 57 
      checks the answerbox and pulls messages from several queues associated
58 
      with it. After completing the requested action, server sends a reply
 58 
      with it. After completing the requested action, server sends a reply
59 
      back to the answerbox of the originating task. If a need arises, it is
 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
 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
 61 
      of the open phones to another task. This mechanism is used e.g. for
62 
      opening new connections.</para>
 62 
      opening new connections.</para>
63 
 
 63 
 
- 
 
 64 
      <para>The answerbox contains four different message queues:</para>
- 
 
 65 
 
- 
 
 66 
      <itemizedlist>
- 
 
 67 
        <listitem>
- 
 
 68 
          <para>Incoming call queue</para>
- 
 
 69 
        </listitem>
- 
 
 70 
 
- 
 
 71 
        <listitem>
- 
 
 72 
          <para>Dispatched call queue</para>
- 
 
 73 
        </listitem>
- 
 
 74 
 
- 
 
 75 
        <listitem>
- 
 
 76 
          <para>Answer queue</para>
- 
 
 77 
        </listitem>
- 
 
 78 
 
- 
 
 79 
        <listitem>
- 
 
 80 
          <para>Notification queue</para>
- 
 
 81 
        </listitem>
- 
 
 82 
      </itemizedlist>
- 
 
 83 
 
- 
 
 84 
      <para>The communication between task A, that is connected to task B
- 
 
 85 
      looks as follows: Task A sends a message over it's phone to the target
- 
 
 86 
      asnwerbox. The message is saved in task B incoming call queue. When task
- 
 
 87 
      B fetches the message for processing, it is automatically moved into the
- 
 
 88 
      dispatched call queue. After the server decides to answer the message,
- 
 
 89 
      it is removed from dispatched queue and the result is moved into the
- 
 
 90 
      answer queue of task A.</para>
- 
 
 91 
 
64 
      <para>The arguments contained in the message are completely arbitrary
 92 
      <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
 93 
      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
 94 
      appropriate error codes if there is an error during communication. It is
67 
      ensured that the applications are correctly notified about communication
 95 
      assured that the applications are correctly notified about communication
68 
      state. If the outgoing connection is closed with the hangup message, the
 96 
      state. If a program closes the outgoing connection, the target answerbox
69 
      target answerbox receives a hangup message. The connection
 97 
      receives a hangup message. The connection identification is not reused,
70 
      identification is not reused, until the hangup message is acknowledged
 98 
      until the hangup message is acknowledged and all other pending messages
71 
      and all other pending messages are answered.</para>
 99 
      are answered.</para>
72 
 
 100 
 
73 
      <para>If the server side decides to hangup an incoming connection, it
 101 
      <para>Closing an incoming connection is done by responding to any
74 
      does it by responding to any incoming message with an EHANGUP error
 102 
      incoming message with an EHANGUP error code. The connection is then
75 
      code. The connection is then immediately closed. The client connection
 103 
      immediately closed. The client connection identification (phone id) is
76 
      identification (phone id) is not reused, until the client issues hangup
 104 
      not reused, until the client issues closes it's own side of the
77 
      system call to close the outgoing connection.</para>
 105 
      connection ("hangs his phone up").</para>
78 
 
 106 
 
79 
      <para>When a task dies (whether voluntarily or by being killes), cleanup
 107 
      <para>When a task dies (whether voluntarily or by being killed), cleanup
80 
      process is started which performs following tasks.</para>
 108 
      process is started. </para>
81 
 
 109 
 
82 
      <orderedlist>
 110 
      <orderedlist>
83 
        <listitem>
 111 
        <listitem>
84 
          <para>Hangs up all outgoing connections and sends hangup messages to
 112 
          <para>Hangs up all outgoing connections and sends hangup messages to
85 
          all target answerboxes.</para>
 113 
          all target answerboxes.</para>
Line 131... Line 159...
131 
 
 159 
 
132 
        <listitem>
 160 
        <listitem>
133 
          <para>Asking for an address space area</para>
 161 
          <para>Asking for an address space area</para>
134 
        </listitem>
 162 
        </listitem>
135 
      </itemizedlist>
 163 
      </itemizedlist>
- 
 
 164 
 
- 
 
 165 
      <para>On startup every task is automatically connected to a
- 
 
 166 
      <emphasis>name service task</emphasis>, which provides a switchboard
- 
 
 167 
      functionality. To open a new outgoing connection, the client sends a
- 
 
 168 
      <constant>CONNECT_ME_TO</constant> message using any of his phones. If
- 
 
 169 
      the recepient of this message answers with an accepting answer, a new
- 
 
 170 
      connection is created. In itself, this mechanism would allow only
- 
 
 171 
      duplicating existing connection. However, if the message is forwarded,
- 
 
 172 
      the new connection is made to the final recipient. </para>
- 
 
 173 
 
- 
 
 174 
      <para>On startup every task is automatically connect to the name service
- 
 
 175 
      task, which acts as a switchboard and forwards requests for connection
- 
 
 176 
      to specific services. To be able to forward a message it must have a
- 
 
 177 
      phone connected to the service tasks. The task creates this connection
- 
 
 178 
      using a <constant>CONNECT_TO_ME</constant> message which creates a
- 
 
 179 
      callback connection. Every service that wants to receive connections
- 
 
 180 
      asks name service task to create a callback connection.</para>
- 
 
 181 
 
- 
 
 182 
      <para>Tasks can share their address space areas using IPC messages. The
- 
 
 183 
      2 message types - AS_AREA_SEND and AS_AREA_RECV are used for sending and
- 
 
 184 
      receiving an address area respectively. The shared area can be accessed
- 
 
 185 
      as soon as the message is acknowledged. </para>
136 
    </section>
 186 
    </section>
137 
  </section>
 187 
  </section>
138 
 
 188 
 
139 
  <section>
 189 
  <section>
140 
    <title>Userspace view</title>
 190 
    <title>Userspace view</title>
Line 183... Line 233...
183 
      cached within the application. This behaviour is enforced automatically
 233 
      cached within the application. This behaviour is enforced automatically
184 
      and the decision making is hidden from developers view.</para>
 234 
      and the decision making is hidden from developers view.</para>
185 
    </section>
 235 
    </section>
186 
 
 236 
 
187 
    <section>
 237 
    <section>
188 
      <title>Synchronization problem</title>
 238 
      <title>Ordering problem</title>
189 
 
 239 
 
190 
      <para>Unfortunately, in the real world is is never so easy. E.g. if a
 240 
      <para>Unfortunately, in the real world is is never so easy. E.g. if a
191 
      server handles incoming requests and as a part of it's response sends
 241 
      server handles incoming requests and as a part of it's response sends
192 
      asynchronous messages, it can be easily prempted and other thread may
 242 
      asynchronous messages, it can be easily prempted and other thread may
193 
      start intervening. This can happen even if the application utilizes only
 243 
      start intervening. This can happen even if the application utilizes only