Thank you for all of you that have commented my post "How do you want to access shared resources?". We are currently working to implement following kind of solution to ( mutual exclusion / shared resource protection / critical region ) issue.
Anyway comments are welcome. Especially operation names and syntactical issues are under consideration.
The following text describes
1) the needs behind the new features 2) a short description of the notation to be improved 3) the new features for ReaGOS kernel 4) the new features for ReaGeniXThe features are to be included in the next version of CASE-tool & RTOS combination ReaGeniX & ReaGOS.
The needs driving the development of the new features:
- Effectiveness of internal communication of the target software
- Reliability of the target software developed by our tools
First a short description of our notation to get an idea where the new features will be added.
Our graphical notation is a structured one. The basic idea is to define and interconnect functional blocks. The functional blocks have interfaces with strongly typed asymmetric connectors. There are two kind of diagrams to define new functional block types: architecture diagrams and state diagrams. In architecture diagrams instances of functional blocks and data stores (kinds of boxes) are connected to each other and to the diagram interface by lines. In state diagrams there are hierarchical states (kind of nested boxes) and transitions (lines). In transitions textual conditions and actions refer to interface items. Notation is slightly different from Harel's StateCharts. Our notation was already originally designed for generation of efficient target code.
In the topmost architecture diagram the functional blocks can be annotated with priority numbers or "driver". The annotated architecture diagram is called a priority diagram and it can be used to generate/configure the ReaGOS microkernel.
The new features for ReaGOS microkernel are
- Shared store - a store symbol in priority diagram
- New connectors for functional block interfaces to connect to a shared store - shared - for read access to a shared store - shared_W - for read/write access to a shared store
- Locking operations based on priority ceiling protocol
The shared stores with locking operations improve the communication between tasks. No server tasks are needed to protect the data.
Priority ceiling protocol keeps the locking operations simple, avoids priority inversion, and avoids deadlocks.
The new features of ReaGeniX graphical language and code generator
- New connectors shared and shared_W to support ReaGOS or other OS - Separate shared connectors for inter-task data and store connectors for intra-task data allow generation/compile-time assurance that inter-task data must be locked during access, but no overhead is introduced to intra-task store access.
- Separation of store and store_W (read and read/write) connectors for data stores. Earlier only read/write connector was available. -This is to keep better track who is updating (and possibly messing up) a store.
- A locking operator "lock(X)" to be used in transition condition, if the expression refers to a shared store connector X
- A release operator "unlock_all" to release all shared stores locked in condition. This is to be used in the outermost block level of the transition action.
- A locking block construct "begin_lock(X) ... end_lock(X)" to protect X from modification (read lock)
- A locking block construct "begin_lock_W(X) ... end_lock_W(X)" to protect X from all other accessess (write lock)
- A mechanism to discourage accessess of a shared store outside of locks and to discourage modification of a shared store outside of write locks.
All comments are welcome!
Regards,
Ari Okkonen OBP Research Oy