9,8 → 9,8 |
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 |
a special layer providing a user application developer a reasonably |
applications. HelenOS implements fully asynchronous messaging system with a |
special layer providing a user application developer a reasonably |
synchronous multithreaded environment sufficient to develop complex |
protocols.</para> |
|
247,7 → 247,6 |
<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 |
274,30 → 273,43 |
<section> |
<title>Ordering problem</title> |
|
<para>Unfortunately, in the real world is is never so easy. E.g. if a |
server handles incoming requests and as a part of it's response sends |
<para>Unfortunately, the real world is is never so simple. E.g. if a |
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 |
1 kernel thread. Classical synchronization using semaphores is not |
possible, as locking on them would block the thread completely and the |
answer couldn't be ever processed. The IPC framework allows a developer |
to specify, that the thread should not be preempted to any other thread |
(except notification handlers) while still being able to queue messages |
belonging to other threads and regain control when the answer |
arrives.</para> |
possible, as locking on them would block the thread completely so that |
the answer couldn't be ever processed. The IPC framework allows a |
developer to specify, that part of the code should not be preempted by |
any other thread (except notification handlers) while still being able |
to queue messages belonging to other threads and regain control when the |
answer arrives.</para> |
|
<para>This mechanism works transparently in multithreaded environment, |
where classical locking mechanism (futexes) should be used. The IPC |
framework ensures that there will always be enough free threads to |
handle the threads requiring correct synchronization and allow the |
application to run more user-space threads inside the kernel threads |
without the danger of locking all kernel threads in futexes.</para> |
where additional locking mechanism (futexes) should be used. The IPC |
framework ensures that there will always be enough free kernel threads |
to handle incoming answers and allow the application to run more |
user-space threads inside the kernel threads without the danger of |
locking all kernel threads in futexes.</para> |
</section> |
|
<section> |
<title>The interface</title> |
|
<para></para> |
<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 |
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> |