| 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> |
| |
| 228,7 → 228,7 |
|---|
| 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"> |
| 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> |