25 Oct
2017
25 Oct
'17
10:30 p.m.
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?
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"
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?
If A has a lock on the mutex, then C requests a lock, will this cause A to
be unable to release the lock?
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?
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?
I'm relatively new to this and am trying to build a system with the help of
camkes and I want to make sure I understand this before I get too far. I
don't want to be working under incorrect assumptions.
Thanks for taking the time to read this.
Sincerely,
Jeff Brandon
Associate Staff
MIT Lincoln Laboratory
Secure Resilient Systems and Technology
Ph: +1 781.981.9233
6 Nov
6 Nov
1:46 a.m.
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/seL4MyConne…).
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
2:22 a.m.
On 05/11/17 16:46, Adrian.Danis(a)data61.csiro.au wrote:
If I can add to Adrian's comments, that example demonstrates a possible way of
implementing a lock server in CAmkES, not
necessarily the best way. For example, if the control flow in your system results in only
one thread ever accessing the
lock, there's no advantage to using a CAmkES mutex over just a standard variable.
I.e. if your system architecture
already synchronizes access to the state, there's no point layering this on top of
the mutex's synchronization
mechanisms as well. My point is, this example is useful for learning how CAmkES works, but
if you are building a larger
system I would not consider it an idiomatic example of how to implement cross-component
locks.
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?
1696
days inactive
1708
days old
2 comments
3 participants
participants (3)
-
Adrian.Danis＠data61.csiro.au -
Brandon, Jeffrey - 0553 - MITLL -
Matthew Fernandez