@alexfru
We did not implement a deadlock detection mechanism. As far as we know, there is no O(1) or O(log(N)) deadlock detection mechanism. If you know one, we will be more than happy to implement it!
We do implement a semaphore ceiling which, if used correctly, can prevent deadlocks (note that there are some conditions required for deadlocks to be prevented when using ceiling semaphores).
We also allow a partition to obtain a "resource" from another partition for access in mutual exclusion. This resource is controlled also via a semaphore ceiling but, when inside the resource:
- the thread stack is changed to a special stack
- the memory permissions changed to the memory permissions of the resource owner partition
- the access to the resource is only allowed if the executing thread has a big enough time window to successfully complete the resource (each resource has a configurable WCET) without exhausting its time window -> this is to ensure that once a thread has access to a resource it can complete it without other lower priority threads preempting it
Do you have an application in mind for pharos?
@Schol-R-LEA
Thanks for giving your point of view. I had not think about this hard/soft issue from that perspective. Nevertheless, I think that even if the audience is not familiar with some concepts, one could transmit the knowledge so that an understanding could be reached, hopefully.
There is a well defined difference between hard/firm/soft real time based on the "utility" of the system as time goes by. I guess this well documented and one can google it can find hundreds of explanations for this so I cannot add anything new.
But in the "real world" this definition is...not used at all (at least I never encountered it). Typically what is done is:
- there is a standard that defines the level of criticality of your system based on what could happen if the system does not operate correctly (e.g. lives are lost, equipment is damaged, a person could feel uncomfortable, a person was not see any behavior at all). This is quite similar to the utility function, but normally the standards define more levels (than the 3 hard/firm/soft)
- based on the critical level, the standard defines which "proofs" you must produce to certify your system to that level (e.g. coding standard, tests, etc)
When reading the question of whether pharos is for hard/soft real time I was in doubt if the question was related to this "criticality" definition or was related to the API provided or whatever. So, to try to answer again to the question, pharos:
- has an API design for hard real time systems
- the source code was written so that the certification proofs would be easier to provide (if the opportunity arises for this)
- pharos is NOT certified today to any standard
I hope to have clarified any doubt related to this issue. But your answer has proven to me that are multiple ways to see the same subject, so if this answer did not satisfy you (or anyone else) please let me know
Thanks,
Pedro
