Rev 169 | Only display areas with differences | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed
| Rev 169 | Rev 171 | ||
|---|---|---|---|
| 1 | <?xml version="1.0" encoding="UTF-8"?> |
1 | <?xml version="1.0" encoding="UTF-8"?> |
| 2 | <chapter id="ipc"> |
2 | <chapter id="ipc"> |
| 3 | <?dbhtml filename="ipc.html"?> |
3 | <?dbhtml filename="ipc.html"?> |
| 4 | 4 | ||
| 5 | <title>IPC</title> |
5 | <title>IPC</title> |
| 6 | 6 | ||
| 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 fully asynchronous messaging system with a |
12 | applications. HelenOS implements fully asynchronous messaging system with a |
| 13 | special layer providing a user application developer a reasonably |
13 | 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>Kernel Services</title> |
18 | <title>Kernel Services</title> |
| 19 | 19 | ||
| 20 | <para>Every message consists of four numeric arguments (32-bit and 64-bit on |
20 | <para>Every message consists of four numeric arguments (32-bit and 64-bit |
| 21 | the corresponding platforms), from which the first one is considered a |
21 | on 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 the receiving application can distinguish the messages between |
24 | that the receiving application can distinguish the messages between |
| 25 | different senders. Internally the message contains pointer to the |
25 | different senders. Internally the message contains pointer to the |
| 26 | originating task and to the source of the communication channel. If the |
26 | originating task and to the source of the communication channel. If the |
| 27 | message is forwarded, the originating task identifies the recipient of the |
27 | message is forwarded, the originating task identifies the recipient of the |
| 28 | answer, the source channel identifies the connection in case of a hangup |
28 | answer, the source channel identifies the connection in case of a hangup |
| 29 | response.</para> |
29 | response.</para> |
| 30 | 30 | ||
| 31 | <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 |
| 32 | 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 |
| 33 | should one of the connection parties fail unexpectedly. To limit buffering |
33 | should one of the connection parties fail unexpectedly. To limit buffering |
| 34 | of the messages in the kernel, every task has a limit on the amount of |
34 | of the messages in the kernel, every task has a limit on the amount of |
| 35 | asynchronous messages it can send simultaneously. If the limit is reached, |
35 | asynchronous messages it can send simultaneously. If the limit is reached, |
| 36 | the kernel refuses to send any other message until some active message is |
36 | the kernel refuses to send any other message until some active message is |
| 37 | answered.</para> |
37 | answered.</para> |
| 38 | 38 | ||
| 39 | <para>To facilitate kernel-to-user communication, the IPC subsystem |
39 | <para>To facilitate kernel-to-user communication, the IPC subsystem |
| 40 | provides notification messages. The applications can subscribe to a |
40 | provides notification messages. The applications can subscribe to a |
| 41 | notification channel and receive messages directed to this channel. Such |
41 | notification channel and receive messages directed to this channel. Such |
| 42 | messages can be freely sent even from interrupt context as they are |
42 | messages can be freely sent even from interrupt context as they are |
| 43 | primarily destined to deliver IRQ events to userspace device drivers. |
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 |
44 | These messages need not be answered, there is no party that could receive |
| 45 | such response.</para> |
45 | such response.</para> |
| 46 | 46 | ||
| 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 call other tasks and connect its phones to their answerboxes, |
52 | task can call other tasks and connect its phones to their answerboxes, |
| 53 | send 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. The server application periodically |
56 | the phone to the target answerbox. The 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, the server sends a reply |
58 | with it. After completing the requested action, the 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 received message through any |
60 | possible to <emphasis>forward</emphasis> a received message through 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 to services via the naming service.</para> |
62 | opening new connections to services via the naming service.</para> |
| 63 | 63 | ||
| 64 | <para>The answerbox contains four different message queues:</para> |
64 | <para>The answerbox contains four different message queues:</para> |
| 65 | 65 | ||
| 66 | <itemizedlist> |
66 | <itemizedlist> |
| 67 | <listitem> |
67 | <listitem> |
| 68 | <para>Incoming call queue</para> |
68 | <para>Incoming call queue</para> |
| 69 | </listitem> |
69 | </listitem> |
| 70 | 70 | ||
| 71 | <listitem> |
71 | <listitem> |
| 72 | <para>Dispatched call queue</para> |
72 | <para>Dispatched call queue</para> |
| 73 | </listitem> |
73 | </listitem> |
| 74 | 74 | ||
| 75 | <listitem> |
75 | <listitem> |
| 76 | <para>Answer queue</para> |
76 | <para>Answer queue</para> |
| 77 | </listitem> |
77 | </listitem> |
| 78 | 78 | ||
| 79 | <listitem> |
79 | <listitem> |
| 80 | <para>Notification queue</para> |
80 | <para>Notification queue</para> |
| 81 | </listitem> |
81 | </listitem> |
| 82 | </itemizedlist> |
82 | </itemizedlist> |
| 83 | 83 | ||
| 84 | <figure float="1"> |
84 | <figure float="1"> |
| 85 | <title>Low level IPC</title> |
85 | <title>Low level IPC</title> |
| 86 | 86 | ||
| 87 | <mediaobject id="ipc1"> |
87 | <mediaobject id="ipc1"> |
| 88 | <imageobject role="pdf"> |
88 | <imageobject role="pdf"> |
| 89 | <imagedata fileref="images/ipc1.pdf" format="PDF" /> |
89 | <imagedata fileref="images/ipc1.pdf" format="PDF" /> |
| 90 | </imageobject> |
90 | </imageobject> |
| 91 | 91 | ||
| 92 | <imageobject role="html"> |
92 | <imageobject role="html"> |
| 93 | <imagedata fileref="images/ipc1.png" format="PNG" /> |
93 | <imagedata fileref="images/ipc1.png" format="PNG" /> |
| 94 | </imageobject> |
94 | </imageobject> |
| 95 | 95 | ||
| 96 | <imageobject role="fop"> |
96 | <imageobject role="fop"> |
| 97 | <imagedata fileref="images/ipc1.svg" format="SVG" /> |
97 | <imagedata fileref="images/ipc1.svg" format="SVG" /> |
| 98 | </imageobject> |
98 | </imageobject> |
| 99 | </mediaobject> |
99 | </mediaobject> |
| 100 | </figure> |
100 | </figure> |
| 101 | 101 | ||
| 102 | <para>The communication between task A, that is connected to task B |
102 | <para>The communication between task A, that is connected to task B |
| 103 | looks as follows: task A sends a message over its phone to the target |
103 | looks as follows: task A sends a message over its phone to the target |
| 104 | asnwerbox. The message is saved in task B's incoming call queue. When task |
104 | asnwerbox. The message is saved in task B's incoming call queue. When |
| 105 | B fetches the message for processing, it is automatically moved into the |
105 | task B fetches the message for processing, it is automatically moved |
| 106 | dispatched call queue. After the server decides to answer the message, |
106 | into the dispatched call queue. After the server decides to answer the |
| 107 | it is removed from dispatched queue and the result is moved into the |
107 | message, it is removed from dispatched queue and the result is moved |
| 108 | answer queue of task A.</para> |
108 | into the answer queue of task A.</para> |
| 109 | 109 | ||
| 110 | <para>The arguments contained in the message are completely arbitrary |
110 | <para>The arguments contained in the message are completely arbitrary |
| 111 | and decided by the user. The low level part of kernel IPC fills in |
111 | and decided by the user. The low level part of kernel IPC fills in |
| 112 | appropriate error codes if there is an error during communication. It is |
112 | appropriate error codes if there is an error during communication. It is |
| 113 | assured that the applications are correctly notified about communication |
113 | assured that the applications are correctly notified about communication |
| 114 | state. If a program closes the outgoing connection, the target answerbox |
114 | state. If a program closes the outgoing connection, the target answerbox |
| 115 | receives a hangup message. The connection identification is not reused |
115 | receives a hangup message. The connection identification is not reused |
| 116 | until the hangup message is acknowledged and all other pending messages |
116 | until the hangup message is acknowledged and all other pending messages |
| 117 | are answered.</para> |
117 | are answered.</para> |
| 118 | 118 | ||
| 119 | <para>Closing an incoming connection is done by responding to any |
119 | <para>Closing an incoming connection is done by responding to any |
| 120 | incoming message with an EHANGUP error code. The connection is then |
120 | incoming message with an EHANGUP error code. The connection is then |
| 121 | immediately closed. The client connection identification (phone id) is |
121 | immediately closed. The client connection identification (phone id) is |
| 122 | not reused, until the client closes its own side of the |
122 | not reused, until the client closes its own side of the connection |
| 123 | connection ("hangs his phone up").</para> |
123 | ("hangs his phone up").</para> |
| 124 | 124 | ||
| 125 | <para>When a task dies (whether voluntarily or by being killed), cleanup |
125 | <para>When a task dies (whether voluntarily or by being killed), cleanup |
| 126 | process is started.</para> |
126 | process is started.</para> |
| 127 | 127 | ||
| 128 | <orderedlist> |
128 | <orderedlist> |
| 129 | <listitem> |
129 | <listitem> |
| 130 | <para>hangs up all outgoing connections and sends hangup messages to |
130 | <para>hangs up all outgoing connections and sends hangup messages to |
| 131 | all target answerboxes,</para> |
131 | all target answerboxes,</para> |
| 132 | </listitem> |
132 | </listitem> |
| 133 | 133 | ||
| 134 | <listitem> |
134 | <listitem> |
| 135 | <para>disconnects all incoming connections,</para> |
135 | <para>disconnects all incoming connections,</para> |
| 136 | </listitem> |
136 | </listitem> |
| 137 | 137 | ||
| 138 | <listitem> |
138 | <listitem> |
| 139 | <para>disconnects from all notification channels,</para> |
139 | <para>disconnects from all notification channels,</para> |
| 140 | </listitem> |
140 | </listitem> |
| 141 | 141 | ||
| 142 | <listitem> |
142 | <listitem> |
| 143 | <para>answers all unanswered messages from answerbox queues with |
143 | <para>answers all unanswered messages from answerbox queues with |
| 144 | appropriate error code and</para> |
144 | appropriate error code and</para> |
| 145 | </listitem> |
145 | </listitem> |
| 146 | 146 | ||
| 147 | <listitem> |
147 | <listitem> |
| 148 | <para>waits until all outgoing messages are answered and all |
148 | <para>waits until all outgoing messages are answered and all |
| 149 | remaining answerbox queues are empty.</para> |
149 | remaining answerbox queues are empty.</para> |
| 150 | </listitem> |
150 | </listitem> |
| 151 | </orderedlist> |
151 | </orderedlist> |
| 152 | </section> |
152 | </section> |
| 153 | 153 | ||
| 154 | <section> |
154 | <section> |
| 155 | <title>System Call IPC Layer</title> |
155 | <title>System Call IPC Layer</title> |
| 156 | 156 | ||
| 157 | <para>On top of this simple protocol the kernel provides special |
157 | <para>On top of this simple protocol the kernel provides special |
| 158 | services closely related to the inter-process communication. A range of |
158 | services closely related to the inter-process communication. A range of |
| 159 | method numbers is allocated and protocol is defined for these functions. |
159 | method numbers is allocated and protocol is defined for these functions. |
| 160 | These messages are interpreted by the kernel layer and appropriate actions |
160 | These messages are interpreted by the kernel layer and appropriate |
| 161 | are taken depending on the parameters of the message and the answer.</para> |
161 | actions are taken depending on the parameters of the message and the |
| - | 162 | answer.</para> |
|
| 162 | 163 | ||
| 163 | <para>The kernel provides the following services:</para> |
164 | <para>The kernel provides the following services:</para> |
| 164 | 165 | ||
| 165 | <itemizedlist> |
166 | <itemizedlist> |
| 166 | <listitem> |
167 | <listitem> |
| 167 | <para>creating new outgoing connection,</para> |
168 | <para>creating new outgoing connection,</para> |
| 168 | </listitem> |
169 | </listitem> |
| 169 | 170 | ||
| 170 | <listitem> |
171 | <listitem> |
| 171 | <para>creating a callback connection,</para> |
172 | <para>creating a callback connection,</para> |
| 172 | </listitem> |
173 | </listitem> |
| 173 | 174 | ||
| 174 | <listitem> |
175 | <listitem> |
| 175 | <para>sending an address space area and</para> |
176 | <para>sending an address space area and</para> |
| 176 | </listitem> |
177 | </listitem> |
| 177 | 178 | ||
| 178 | <listitem> |
179 | <listitem> |
| 179 | <para>asking for an address space area.</para> |
180 | <para>asking for an address space area.</para> |
| 180 | </listitem> |
181 | </listitem> |
| 181 | </itemizedlist> |
182 | </itemizedlist> |
| 182 | 183 | ||
| 183 | <para>On startup, every task is automatically connected to a |
184 | <para>On startup, every task is automatically connected to a |
| 184 | <emphasis>naming service task</emphasis>, which provides a switchboard |
185 | <emphasis>naming service task</emphasis>, which provides a switchboard |
| 185 | functionality. In order to open a new outgoing connection, the client sends a |
186 | functionality. In order to open a new outgoing connection, the client |
| 186 | <constant>CONNECT_ME_TO</constant> message using any of his phones. If |
187 | sends a <constant>CONNECT_ME_TO</constant> message using any of his |
| 187 | the recepient of this message answers with an accepting answer, a new |
188 | phones. If the recepient of this message answers with an accepting |
| 188 | connection is created. In itself, this mechanism would allow only |
189 | answer, a new connection is created. In itself, this mechanism would |
| 189 | duplicating existing connection. However, if the message is forwarded, |
190 | allow only duplicating existing connection. However, if the message is |
| 190 | the new connection is made to the final recipient.</para> |
191 | forwarded, the new connection is made to the final recipient.</para> |
| 191 | 192 | ||
| 192 | <para>In order for a task to be able to forward a message, it |
193 | <para>In order for a task to be able to forward a message, it must have |
| 193 | must have a phone connected to the destination task. |
194 | a phone connected to the destination task. The destination task |
| 194 | The destination task establishes such connection by sending the <constant>CONNECT_TO_ME</constant> |
195 | establishes such connection by sending the |
| 195 | message to the forwarding task. A callback connection is opened afterwards. |
196 | <constant>CONNECT_TO_ME</constant> message to the forwarding task. A |
| 196 | Every service that wants to receive connections |
197 | callback connection is opened afterwards. Every service that wants to |
| 197 | has to ask the naming service to create the callback connection via this mechanism.</para> |
198 | receive connections has to ask the naming service to create the callback |
| - | 199 | connection via this mechanism.</para> |
|
| 198 | 200 | ||
| 199 | <para>Tasks can share their address space areas using IPC messages. The |
201 | <para>Tasks can share their address space areas using IPC messages. The |
| 200 | two message types - <constant>AS_AREA_SEND</constant> and <constant>AS_AREA_RECV</constant> are used for sending and |
202 | two message types - <constant>AS_AREA_SEND</constant> and |
| - | 203 | <constant>AS_AREA_RECV</constant> are used for sending and receiving an |
|
| 201 | receiving an address space area respectively. The shared area can be accessed |
204 | address space area respectively. The shared area can be accessed as soon |
| 202 | as soon as the message is acknowledged.</para> |
205 | as the message is acknowledged.</para> |
| 203 | </section> |
206 | </section> |
| 204 | </section> |
207 | </section> |
| 205 | 208 | ||
| 206 | <section> |
209 | <section> |
| 207 | <title>Userspace View</title> |
210 | <title>Userspace View</title> |
| 208 | 211 | ||
| 209 | <para>The conventional design of the asynchronous API seems to produce |
212 | <para>The conventional design of the asynchronous API seems to produce |
| 210 | applications with one event loop and several big switch statements. |
213 | applications with one event loop and several big switch statements. |
| 211 | However, by intensive utilization of userspace pseudo threads, it was possible |
214 | However, by intensive utilization of userspace fibrils, it was possible to |
| 212 | to create an environment that is not necessarily restricted to this type |
215 | create an environment that is not necessarily restricted to this type of |
| 213 | of event-driven programming and allows for more fluent expression of |
216 | event-driven programming and allows for more fluent expression of |
| 214 | application programs.</para> |
217 | application programs.</para> |
| 215 | 218 | ||
| 216 | <section> |
219 | <section> |
| 217 | <title>Single Point of Entry</title> |
220 | <title>Single Point of Entry</title> |
| 218 | 221 | ||
| 219 | <para>Each task is associated with only one answerbox. If a |
222 | <para>Each task is associated with only one answerbox. If a |
| 220 | multithreaded application needs to communicate, it must be not only |
223 | multithreaded application needs to communicate, it must be not only able |
| 221 | able to send a message, but it should be able to retrieve the answer as |
224 | to send a message, but it should be able to retrieve the answer as well. |
| 222 | well. If several pseudo threads pull messages from task answerbox, it is a |
225 | If several fibrils pull messages from task answerbox, it is a matter of |
| 223 | matter of coincidence, which thread receives which message. If a particular |
226 | coincidence, which fibril receives which message. If a particular fibril |
| 224 | thread needs to wait for a message answer, an idle |
227 | needs to wait for a message answer, an idle <emphasis>manager</emphasis> |
| 225 | <emphasis>manager</emphasis> pseudo thread is found or a new one is created and |
228 | fibril is found or a new one is created and control is transfered to |
| 226 | control is transfered to this manager thread. The manager threads pop |
229 | this manager fibril. The manager fibrils pop messages from the answerbox |
| 227 | messages from the answerbox and put them into appropriate queues of |
230 | and put them into appropriate queues of running fibrils. If a fibril |
| 228 | running threads. If a pseudo thread waiting for a message is not running, the |
231 | waiting for a message is not running, the control is transferred to |
| 229 | control is transferred to it.</para> |
232 | it.</para> |
| 230 | 233 | ||
| 231 | <figure float="1"> |
234 | <figure float="1"> |
| 232 | <title>Single point of entry</title> |
235 | <title>Single point of entry</title> |
| - | 236 | ||
| 233 | <mediaobject id="ipc2"> |
237 | <mediaobject id="ipc2"> |
| 234 | <imageobject role="pdf"> |
238 | <imageobject role="pdf"> |
| 235 | <imagedata fileref="images/ipc2.pdf" format="PDF" /> |
239 | <imagedata fileref="images/ipc2.pdf" format="PDF" /> |
| 236 | </imageobject> |
240 | </imageobject> |
| 237 | 241 | ||
| 238 | <imageobject role="html"> |
242 | <imageobject role="html"> |
| 239 | <imagedata fileref="images/ipc2.png" format="PNG" /> |
243 | <imagedata fileref="images/ipc2.png" format="PNG" /> |
| 240 | </imageobject> |
244 | </imageobject> |
| 241 | 245 | ||
| 242 | <imageobject role="fop"> |
246 | <imageobject role="fop"> |
| 243 | <imagedata fileref="images/ipc2.svg" format="SVG" /> |
247 | <imagedata fileref="images/ipc2.svg" format="SVG" /> |
| 244 | </imageobject> |
248 | </imageobject> |
| 245 | </mediaobject> |
249 | </mediaobject> |
| 246 | - | ||
| 247 | </figure> |
250 | </figure> |
| 248 | 251 | ||
| 249 | <para>Very similar situation arises when a task decides to send a lot of |
252 | <para>Very similar situation arises when a task decides to send a lot of |
| 250 | messages and reaches the kernel limit of asynchronous messages. In such |
253 | messages and reaches the kernel limit of asynchronous messages. In such |
| 251 | situation, two remedies are available - the userspace library can either |
254 | situation, two remedies are available - the userspace library can either |
| 252 | cache the message locally and resend the message when some answers |
255 | cache the message locally and resend the message when some answers |
| 253 | arrive, or it can block the thread and let it go on only after the |
256 | arrive, or it can block the fibril and let it go on only after the |
| 254 | message is finally sent to the kernel layer. With one exception, HelenOS |
257 | message is finally sent to the kernel layer. With one exception, HelenOS |
| 255 | uses the second approach - when the kernel responds that the maximum limit |
258 | uses the second approach - when the kernel responds that the maximum |
| 256 | of asynchronous messages was reached, the control is transferred to a manager |
259 | limit of asynchronous messages was reached, the control is transferred |
| 257 | pseudo thread. The manager thread then handles incoming replies and, when space |
260 | to a manager fibril. The manager fibril then handles incoming replies |
| 258 | is available, sends the message to the kernel and resumes the application thread |
261 | and, when space is available, sends the message to the kernel and |
| 259 | execution.</para> |
262 | resumes the application fibril execution.</para> |
| 260 | 263 | ||
| 261 | <para>If a kernel notification is received, the servicing procedure is |
264 | <para>If a kernel notification is received, the servicing procedure is |
| 262 | run in the context of the manager pseudo thread. Although it wouldn't be |
265 | run in the context of the manager fibril. Although it wouldn't be |
| 263 | impossible to allow recursive calling, it could potentially lead to an |
266 | impossible to allow recursive calling, it could potentially lead to an |
| 264 | explosion of manager threads. Thus, the kernel notification procedures |
267 | explosion of manager fibrils. Thus, the kernel notification procedures |
| 265 | are not allowed to wait for a message result, they can only answer |
268 | are not allowed to wait for a message result, they can only answer |
| 266 | messages and send new ones without waiting for their results. If the |
269 | messages and send new ones without waiting for their results. If the |
| 267 | kernel limit for outgoing messages is reached, the data is automatically |
270 | kernel limit for outgoing messages is reached, the data is automatically |
| 268 | cached within the application. This behaviour is enforced automatically |
271 | cached within the application. This behaviour is enforced automatically |
| 269 | and the decision making is hidden from the developer.</para> |
272 | and the decision making is hidden from the developer.</para> |
| 270 | 273 | ||
| 271 | <figure float="1"> |
274 | <figure float="1"> |
| 272 | <title>Single point of entry solution</title> |
275 | <title>Single point of entry solution</title> |
| - | 276 | ||
| 273 | <mediaobject id="ipc3"> |
277 | <mediaobject id="ipc3"> |
| 274 | <imageobject role="pdf"> |
278 | <imageobject role="pdf"> |
| 275 | <imagedata fileref="images/ipc3.pdf" format="PDF" /> |
279 | <imagedata fileref="images/ipc3.pdf" format="PDF" /> |
| 276 | </imageobject> |
280 | </imageobject> |
| 277 | 281 | ||
| 278 | <imageobject role="html"> |
282 | <imageobject role="html"> |
| 279 | <imagedata fileref="images/ipc3.png" format="PNG" /> |
283 | <imagedata fileref="images/ipc3.png" format="PNG" /> |
| 280 | </imageobject> |
284 | </imageobject> |
| 281 | 285 | ||
| 282 | <imageobject role="fop"> |
286 | <imageobject role="fop"> |
| 283 | <imagedata fileref="images/ipc3.svg" format="SVG" /> |
287 | <imagedata fileref="images/ipc3.svg" format="SVG" /> |
| 284 | </imageobject> |
288 | </imageobject> |
| 285 | </mediaobject> |
289 | </mediaobject> |
| 286 | - | ||
| 287 | </figure> |
290 | </figure> |
| 288 | </section> |
291 | </section> |
| 289 | 292 | ||
| 290 | <section> |
293 | <section> |
| 291 | <title>Ordering Problem</title> |
294 | <title>Ordering Problem</title> |
| 292 | 295 | ||
| 293 | <para>Unfortunately, the real world is is never so simple. E.g. if a |
296 | <para>Unfortunately, the real world is is never so simple. E.g. if a |
| 294 | server handles incoming requests and as a part of its response sends |
297 | server handles incoming requests and as a part of its response sends |
| 295 | asynchronous messages, it can be easily preempted and another thread may |
298 | asynchronous messages, it can be easily preempted and another thread may |
| 296 | start intervening. This can happen even if the application utilizes only |
299 | start intervening. This can happen even if the application utilizes only |
| 297 | one userspace thread. Classical synchronization using semaphores is not |
300 | one userspace thread. Classical synchronization using semaphores is not |
| 298 | possible as locking on them would block the thread completely so that |
301 | possible as locking on them would block the thread completely so that |
| 299 | the answer couldn't be ever processed. The IPC framework allows a |
302 | the answer couldn't be ever processed. The IPC framework allows a |
| 300 | developer to specify, that part of the code should not be preempted by |
303 | developer to specify, that part of the code should not be preempted by |
| 301 | any other pseudo thread (except notification handlers) while still being able |
304 | any other fibril (except notification handlers) while still being able |
| 302 | to queue messages belonging to other pseudo threads and regain control when the |
305 | to queue messages belonging to other fibrils and regain control when the |
| 303 | answer arrives.</para> |
306 | answer arrives.</para> |
| 304 | 307 | ||
| 305 | <para>This mechanism works transparently in multithreaded environment, |
308 | <para>This mechanism works transparently in multithreaded environment, |
| 306 | where additional locking mechanism (futexes) should be used. The IPC |
309 | where additional locking mechanism (futexes) should be used. The IPC |
| 307 | framework ensures that there will always be enough free userspace threads |
310 | framework ensures that there will always be enough free userspace |
| 308 | to handle incoming answers and allow the application to run more |
311 | threads to handle incoming answers and allow the application to run more |
| 309 | pseudo threads inside the usrspace threads without the danger of |
312 | fibrils inside the userspace threads without the danger of locking all |
| 310 | locking all userspace threads in futexes.</para> |
313 | userspace threads in futexes.</para> |
| 311 | </section> |
314 | </section> |
| 312 | 315 | ||
| 313 | <section> |
316 | <section> |
| 314 | <title>The Interface</title> |
317 | <title>The Interface</title> |
| 315 | 318 | ||
| 316 | <para>The interface was developed to be as simple to use as possible. |
319 | <para>The interface was developed to be as simple to use as possible. |
| 317 | Typical applications simply send messages and occasionally wait for an |
320 | Typical applications simply send messages and occasionally wait for an |
| 318 | answer and check results. If the number of sent messages is higher than |
321 | answer and check results. If the number of sent messages is higher than |
| 319 | the kernel limit, the flow of application is stopped until some answers |
322 | the kernel limit, the flow of application is stopped until some answers |
| 320 | arrive. On the other hand, server applications are expected to work in a |
323 | arrive. On the other hand, server applications are expected to work in a |
| 321 | multithreaded environment.</para> |
324 | multithreaded environment.</para> |
| 322 | 325 | ||
| 323 | <para>The server interface requires the developer to specify a |
326 | <para>The server interface requires the developer to specify a |
| 324 | <function>connection_thread</function> function. When new connection is |
327 | <function>connection_fibril</function> function. When new connection is |
| 325 | detected, a new pseudo thread is automatically created and control is |
328 | detected, a new fibril is automatically created and control is |
| 326 | transferred to this function. The code then decides whether to accept |
329 | transferred to this function. The code then decides whether to accept |
| 327 | the connection and creates a normal event loop. The userspace IPC |
330 | the connection and creates a normal event loop. The userspace IPC |
| 328 | library ensures correct switching between several pseudo threads |
331 | library ensures correct switching between several threads within the |
| 329 | within the kernel environment.</para> |
332 | kernel environment.</para> |
| 330 | </section> |
333 | </section> |
| 331 | </section> |
334 | </section> |
| 332 | </chapter> |
335 | </chapter> |