\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}{}

<!ELEMENT resources (generic_resource | np_resource | 
pip_resource | 
pcp_resource | ipcp_resource | critical_section)+>
<!ELEMENT generic_resource (object_type | name | 
state | size | address | protocol | 
critical_sections | cpu_name | address_space_name)*>
<!ATTLIST generic_resource id ID #REQUIRED>
<!ELEMENT np_resource (object_type | name | state | 
priority | size | address | protocol | critical_sections | 
cpu_name | address_space_name)*>
<!ATTLIST np_resource id ID #REQUIRED>
<!ELEMENT pip_resource (object_type | name | state | 
priority | size | address | protocol | critical_sections | 
cpu_name | address_space_name)*>
<!ATTLIST pip_resource id ID #REQUIRED>
<!ELEMENT pcp_resource (object_type | name | state | 
priority | size | address | protocol | critical_sections | 
cpu_name | address_space_name | ceiling_priority)*>
<!ATTLIST pcp_resource id ID #REQUIRED>
<!ELEMENT ipcp_resource (object_type | name | state | 
priority | size | address | protocol | critical_sections | 
cpu_name | address_space_name | ceiling_priority)*>
<!ATTLIST ipcp_resource id ID #REQUIRED>
<!ELEMENT critical_section (task_begin | task_end)*>


\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}{}

<np_resource id=" 44" >
<object_type>RESOURCE_OBJECT_TYPE</object_type>
	<name>R1</name>
	<state>1</state>
	<size>0</size>
	<address>0</address>
	<protocol>NO_PROTOCOL</protocol>
	<critical_sections>
		<task_name> T1 </task_name> 
		<critical_section>
			<task_begin>1</task_begin>
			<task_end>1</task_end>
		</critical_section>
		<task_name> T2 </task_name> 
		<critical_section>
			<task_begin>1</task_begin>
			<task_end>1</task_end>
		</critical_section>
	</critical_sections>
	<cpu_name>processor1</cpu_name>
	<address_space_name>addr1</address_space_name>
</np_resource>

\end{lstlisting}
\caption{An example of $Resource$ description in Cheddar ADL}
\label{Resource_example}
\end{figure}