On 2011-06-06 02:21, Nicholas Mc Guire wrote: >> >> There are good examples - in the RT domain - for both models. Sharing a >> device does not necessarily mean making things dynamic or even >> unpredictable. >> > > then I maybe dont get the "exclusive" issue you note - if the highest priority task does not have exclusive access - assuming that there is not contention free sharing - how can you give guarantees ? I can imagin sharing if the highest priority has unconstraint access to the reource and any other access is controled by the highest priority task (i.e. queue replication like ARINC 653 queueing ports) but if you have multiple instances of different priority accessing a resource I don't see how this could be done while giving guarantees on timing (assuming that it is not possible to provide all access as physically atomic instructions) Just the classic way: If there is a critical path while accessing the device, make it exclusive via locking. If the length of the critical path is controllable by a low-prio task, you either need to include that workload in the WCET estimation or you need to apply some limits/quotas to prevent unbounded path lengths. > > Do you have an example at hand of such a shared I/O device scheme that can guarantee rt timing ? Let's make it simple: What prevents sharing the process image exposed by an abstract I/O devices in form of a MMIO region between multiple user processes? That you may not rely on the hardware to avoid that processes tap on each other's shoes? But that can be sorted out by privileged driver that enforces access rules, dispatches variable update events to listeners or ensures that only consistent modifications are transferred to the physical process. Where do we loose RT here? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
