Hi Brandon Sorry for the delay, have put some answers inline. Hope they are still of some use to you On Thu 26-Oct-2017 7:30 AM, Brandon, Jeffrey - 0553 - MITLL wrote:

Hi,

I've been taking a look at mutex implementations in the camkes-app example and I had a question.

In the mutex example here https://github.com/seL4/camkes/tree/master/apps/mutex suppose I wanted to extend to add a third component C

I need to add the corresponding camkes, source, Kbuild, and Kconfig files and then I need to add connections to the master mutex.camkes file correct?

No modifications to the Kbuild or Kconfig files should be needed. Just additional source files and extending the Makefile and mutex.camkes to describe the additional components and connections.

My first intuition was to add a connector:

Assembly {

Composition{

.

Connection seL4MyConnector connection(from c.lock, to b.lock);

.

}

}

But this yields and error saying something to the effect "seL4MyConnector expects one from endpoint and two are specified"

This is because seL4MyConenctor is described as have a single 'from' and 'to' Procedure. You could change this by having saying 'from Procedures' instead of 'from Procedure'. Although you would want to make sure that the underlying template is able to handle multiple clients before blindly doing such a thing.

To remedy this I added another lock component to B, and made a connection between C and this new lock B provides. The new lock being implemented by the same template.

My Questions:

In this scenario do A B and C still have access to the same mutex?

No. The actual mutex object is declared in the connector. As you have declared two distinct connections, they each have their own objects, and hence their own mutexes.

If A has a lock on the mutex, then C requests a lock, will this cause A to be unable to release the lock?

As per above answer, the connection used by A and C are completely independent and will not interfere with each other in any way.

In my mental model I have three threads of control, one each for A B and C, if A has a lock and then C requests a lock, does this block B (when it receives a message from C and is now blocked on requesting the mutex)? Then when A tries to release, B is blocked and cannot release the mutex on A's behalf. To put it another way, does this mutex example rely on B having direct access to the templated code and there only being two components?

There are more threads in the system than you expect. Specifically there is a control thread for each of the components, although this only exists because of the 'control' (https://github.com/seL4/camkes/blob/master/apps/mutex/components/A/A.camkes#...) specifier in the component. For a call from A to be received by B though it needs to someone be checking for messages, which you can see the 'run' function (https://github.com/seL4/camkes/blob/master/apps/mutex/components/B/src/main....) in B does not do. As a result there is another thread generated by the 'to' side of the template that is waiting for messages from A (https://github.com/seL4/camkes/blob/master/apps/mutex/templates/seL4MyConnec...). B is able to directly invoke the mutex, and does so for performance reasons. You could also connect B to itself and have it use the RPC interface as well.

Secondarily, in the lockserver example https://github.com/seL4/camkes/tree/master/apps/lockserver a situation is presented where three clients access a single mutex through a single server. Would there be an issue if one of the clients also acted as the server? So for instance if A implemented the three pairs of lock unlock functions instead of the server and then B and C used seL4RPCCall connections to A in order to access them, would there be any synchronization issues?

There is no specific issue with having a client also be the server, it just a bit of a strange design to 'arbitrarily' pick one client to act as the server. Why should that client be given the authority to manage all the locks? Adrian