Hi everyone,

this week I managed to implement:
 - quite simple lock mechanism using the futex_sleep and futex_wakeup
syscall. After an implementation that was not secure I fixed it
yesterday (the discussion can be found in the comment section at [1].
@Stefan: I am aware that this implementation is using more syscalls than
the cmpxchg&sleep approach. But since the waiting threads are not "busy
waiting" I consider this approach being superior.)
 - marshalling of capabilities, which is the Genode way of handing over /
sharing ipc connections
 - thread-specific call queues. Since Stefan and I decided when we last met
that a task-global call queue for all threads of one task is getting locked
way too many times and therefore all threads are blocking each other, we
decided that the manager thread (the only thread looking up the answer box
and storing all incoming calls in call queues) will store the incomming
calls in thread-specific call queues. So in result of that only the manager
thread and the associated worker thread is using one single call queue
reducing the amount of executed locks on one single call queue.
My goals for the upcoming week are:
 - implement request and answer from a client to a server like discussed in
my last weeks report
 - optimise the ipc call queues as following: every time the call queue is
empty or the worker thread is producing a miss when searching fo a specific
call in the call queue, the manager thread is acquiring the lock for this
call queue. The manager thread is unlocking the call queue as soon as a new
call has been inserted into the call queue. This behaviour would eliminate
the currently done busy waiting of the worker thread when waiting for a
specific call or when waiting for a call whenever the call queue is empty.
 - begin to document the my work at [2] as requested with a special focus
on the design of the portation of the ipc framework

Cheers,
Tobias



[1]
https://github.com/kurbel/genode/commit/5bcf3d16fe1af6a26e3de9745534d8f156253c18
[2] http://trac.helenos.org/
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Reply via email to