On 05/11/17 16:46, Adrian.Danis@data61.csiro.au wrote:
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?
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.