\subsubsection{Resource} \label{resource} A \resource is specified by the following definitions:\\ (1) It models any synchronized data structure shared by tasks. \\ (2) It is statically defined in an \addressspace.\\ (3) It models asynchronous communication between tasks of the same \addressspace.\\ \begin{center} Standards attributes \end{center} $State$: It is the initial value of the resource component (similar to a semaphore initial value). During a scheduling simulation, at a given time, if a resource value is equal or less than zero, the requesting tasks are blocked until the semaphore/shared resource is released. An initial value equal to $1$ allows you to design a shared resource that is initially free and that can be used by only one task at a given time.\\ $Size$: It defines the size of the \resource.\\ $Address$: It is the location of the \resource.\\ $Protocol$: It characterises how the \resource is locked and unlocked. Currently, you can choose between \cite{Chen90} \cite{Sha90} PCP (for Priority Ceiling Protocol), PIP (for Priority Inheritance Protocol), IPCP (Immediate Priority Ceiling Protocol) or \textit{No protocol}. With PCP, IPCP or PIP, accessing shared resources may change task priorities. With \textit{No protocol}, the tasks are inserted in a FIFO order in the semaphore queue and no priority inheritance will be applied at simulation time. $Critical_{-}Sections$: It specifies when each \task must lock or unlock resources. This attribute specifies critical sections defined for each \task and \resource.\\ A critical section is defined by two relative instants : $Begin$ and $End$. $Begin$ is the first unit of time of the task capacity when the task needs the resource, i.e. before running $Begin$th unit of time of its capacity, the task locks the \resource component. $End$ is the last unit of time of the task capacity when the task needs the resource, i.e. when the task has ran the $End$th unit of time of its capacity, the task unlocks the \resource component. $Cpu_{-}Name$: Each shared resource has to be located on a given \processor.\\ $Address_{-}Space_{-}Name$: Its stores the name of \addressspace which hosted the \resource.\\ $Priority$: Is of type of $Priority_-Range$ and it defines the ceiling priority of the \resource.\\ This attribute is currently only used with the PCP and ICPP protocols. $Priority_-Assignment$: It is an enumerated type, and characterize the way that Cheddar assigns ceiling priority to the \resource.\\ \begin{center} Legality rules \end{center} (L1) The resource name is mandatory.\\ (L2) The resource name must be a valid identifier.\\ (L3) The $Cpu_{-}Name$ is mandatory.\\ (L4) The $Address_{-}Space_{-}Name$ is mandatory.\\ (L5) The types of $Protocol$ are specified in $Annexes$.\\ (L6) The $Size$ must be greater than or equal to 0.\\ (L7) The $Address$ must be greater than or equal to 0.\\ (L8) The $State$ must be greater than or equal to 0.\\ \begin{center} Annexes \end{center} (A1) Each critical section is defined by :\\ \indent \indent (A11) $Task_-begin$: The time at which the critical section is started. Task is the \task name accessing the shared \resource. \\ \indent \indent (A12) $task_-end$: The time at which the critical section is completed. Task is the \task name accessing the shared \resource. \\ Each of this date are relative to the task capacity. Finally, several critical sections can be defined for a given task on a given resource.\\ (A2) The types of $Protocol$ \cite{McCormick11}.\\ \indent \indent (A21) $No_{-}Protocol$: The \resource is accessed by a FIFO order and no priority inheritance is applied.\\ \indent \indent (A22) $Priority_{-}Inheritance_{-}Protocol$: A \task which blocks a high priority task due to a critical section, sees its priority to be increased to the priority level of the blocked task. $Priority_{-}Inheritance_{-}Protocol$ should not be used with more than one shared resource due to deadlock.\\ \indent \indent \indent \indent (A23) A ceiling priority of a resource is the maximum $Priority$ of all the task component which use the resource.\\ \indent \indent (A24) $Priority_{-}Ceiling_{-}Protocol$: In the case of $Priority_{-}Ceiling_{-}Protocol$, a ceiling priority is assigned to each resource. The ceiling priority can be automatically computed by Cheddar or provided by the user thanks to the $Priority$ attribute of \resource components. A \task which blocks a high priority task due to a critical section, sees its priority to be increased upto the ceiling priority level of the resource. At request time, a task is blocked when its priority level is not strickly higher than every previously allocated resource ceiling priority, except the resource the requesting has allocated. \\ \indent \indent (A25) $Immediate_{-}Priority_{-}Ceiling_{-}Protocol$: with IPCP, a task has a static and a dynamic priority level. The task is run according to its dynamic priority level. Its static priority level is the one stored in the \task $Priority$ attributes. When a task allocates a IPCP \resource, it sees it dynamic priority level increased upto the ceiling priority level of the \resource component. Similarly, the \task priority is decreased when the \resource is unlocked. Again, the ceilin priority can be automatically computed by Cheddar or provided by the user thanks to the $Priority$ attribute of \resource components. \\ \indent \indent \indent \indent (A251) Dynamic task priority = maximum of its own static priority and the ceiling priorities of any resources it has locked.\\ (A3) The types of $Priority_-Assignment$:\\ \indent \indent (A26) $Automatic_-Assignment$: In this case, Cheddar assigns automatically ceiling priority to the \resource. The attribute $Priority$ is then ignored during simulation.\\ \indent \indent (A27) $Manual_-Assignment$: This case corresponds to the manually affectation of $Priority$ to the \resource. The attribute $Priority$ is then used during the simulation. \\ \begin{center} Implementation \end{center} The figure \ref{dtd_resource} gives the DTD of entity \resource. \begin{figure}{} \begin{lstlisting}{} \end{lstlisting} \caption{The DTD of entity \resource} \label{dtd_resource} \end{figure} \begin{center} Example \end{center} An example of resource described in Cheddar ADL is given in figure \ref{Resource_example}. Since $protocol$ has value $NO_{-}PROTOCOL$, it means that no priority inheritance is applied to the task when it holds the resource $R1$. We can also notice that this resource concerns $processor1$, and runs at $addr1$, and has two critical sections: each task holds and releases the resource at time unit $1$. \begin{figure}{} \begin{lstlisting}{} RESOURCE_OBJECT_TYPE R1 1 0
0
NO_PROTOCOL T1 1 1 T2 1 1 processor1 addr1 \end{lstlisting} \caption{An example of $Resource$ description in Cheddar ADL} \label{Resource_example} \end{figure}