Hi Tobias, On 16.07.2012 15:21, Tobias Börtitz wrote: > Hey, > > last week hasn't been so productive, as I tried to solve some issues > which I do not have to solve because they are being implemented in > another way (e.g. I implemented a protocol to be able to ask for a > connection which is then being cloned. But I only had to make cloning a > connection accessible for Genode). But after meeting with Stefan on > Thursday I think that I am back on track. > Aside from the problems I managed to solve last weeks problem with the > manager thread for incoming ipc connections. > So for this week I plan to implement the marshaling of capabilities > (sending cloned connections via the Genode interface) and push forward > the implementation of the ipc manager. To be able to do this I will have > to implement the threads abstraction, since I want to move the > callqueue, which is currently implemented in the ipc manager, to every > single worker thread. This is because the queue has to be locked for > every operation that is performed with it, so having a single global > call queue is not that good because of potentially high amount of > threads which are waiting to get the lock and therefore currently > blocking each other.
Ok, some thoughts to that. First you don't need to implement the whole thread abstraction by now. My advice was to have a per thread-object for the Spartan platform, that contains things like synchronization objects when dealing with the answer-box, whether it is served by a dedicated thread, or by alternating threads (the ones which want to receive messages anyway). Moreover, it could contain message-buffer(s) for the thread. Having such a class would be sufficient right now to finish the IPC framework implementation (in it's current state it is missing any synchronization primitives). Later, when enabling the Thread abstraction in Genode, you can use that class as 'Native_utcb' in Genode's generic Thread class. Furthermore, we've talked about how capability transfer in Genode's IPCs can be implemented using connection cloning. We agreed that a single word (e.g. first position) can be reserved in the message body to signal the other side how many connection-clones will follow that ipc-message, so that the whole message including all following capabilities (capability == Spartan-connection and an id) will be received before the message is given to the higher leveled abstractions. > Furthermore locks (using compare&exchange) and > mutexes (using futex related syscalls) have to be implemented to even be > able to lock something ;) You don't need to implement cmpxchg, it is available in <cpu/atomic.h>. But you're right you need a lock-primitive. My advice was to implement a very simple (but ineffcient variant) like the one in base-fiasco/src/lock/lock.cc with cmpxchg and sleep. Later when you've implemented most platform abstractions, you can implement the more efficient variant based on the generic lock implementation (hereby the futex syscall interface will be of great help). > Additionally I will have to cope with the question how to distinguish > between ipc calls which are aactual request and ipc calls which are > replies to a previously send call (for asynchronous send calls). The > best way would probably be to send an argument which represents a > "referenced callid" with every call. It would be the actual callid from > the referenced call when the call itself is an answer, and otherwise be > zero. Another way could be to generate a hash which is used to identify > a single "conversation" (maybe even incrementing the hash by 1 for every > answer) and send this hash as an argument with every call. > I would be thankfull for any thoughts and ideas. We've already talked about that point, and I suggested that you use the capability id, that is transfered by every ipc-call (at least on most platforms) to the destination-side (to identify the remote-object), as return value to identify a reply. So no extra 'callid' is needed. But I would await Martin's arguments, in the other mail-subthread regarding the long-reply-messages. Regards Stefan > > Regards, > Tobias > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel > -- Stefan Kalkowski Genode Labs http://www.genode-labs.com/ · http://genode.org/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
