23.08.2013 Views

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

6.3 Communication 175<br />

There is a grain <strong>of</strong> behaviour where interrupts can take place. At the moment <strong>of</strong> an<br />

interrupt request the object will normally be busy with the execution <strong>of</strong> some process<br />

statement. Immediately after the execution <strong>of</strong> the present statement the rendezvous<br />

for the interrupt message must be performed. The continuation behaviour can be<br />

a method implementing the required interrupting behaviour, possibly followed by a<br />

return to the original behaviour. The grain <strong>of</strong> behaviour where interrupts can take<br />

place is the atomic process statement. These atomic statements are message-send and<br />

receive statements, method calls, and data statements. These atomic statements cannot<br />

be interrupted. Composite process statements can be interrupted between the atoms that<br />

compose them. The semantics <strong>of</strong> POOSL (see Chapter 9) define that statements are not<br />

taken into execution if they cannot be completed. So a message statement is not taken<br />

into execution until a rendezvous can be performed. This means that there is no risk<br />

that interrupts are blocked by the waiting for a communication.<br />

Examples <strong>of</strong> the use <strong>of</strong> interrupt and abort statements are:<br />

¢<br />

aS1; ¡ ¡ aS2; aSn£ ; abort ch?m<br />

¢<br />

aS1; ¡ ¡ aS2; aSn£ ; interrupt ch?m<br />

Their meaning is that message m on channel ch can respectively abort or interrupt the<br />

behaviour that is specified as the sequence <strong>of</strong> atomic statements ¢<br />

aS1; ¡ ¡ aS2; aSn£ ; .<br />

Notice that we mentioned data statements as one <strong>of</strong> the possible atomic actions. They<br />

are considered here because process statements can be data statements also. A data<br />

statement may be a composite statement. This can mean that a composition <strong>of</strong> data<br />

statements, being a data statement itself, cannot be interrupted at the instants between<br />

the execution <strong>of</strong> the individual data statements. To model realistic real-time behaviour<br />

it could be necessary to allow the interrupt <strong>of</strong> a composite data statement. It appeared<br />

to be a matter <strong>of</strong> interpretation <strong>of</strong> the (data) statement separator ’;’ whether a composite<br />

data statement can be interrupted or not. This was observed during the development<br />

<strong>of</strong> the POOSL compiler. We decided to interpret the statement separator always as a<br />

process statement separator [Kup96].<br />

Summary:<br />

An interrupt message symbol represents a synchronous message passing that can be<br />

forced to happen after the current atomic process statement is finished. POOSL <strong>of</strong>fers<br />

two primitives for the description <strong>of</strong> the behaviour <strong>of</strong> an interrupt flow. An interrupt<br />

specifies that the current behaviour can be resumed, after the interrupt behaviour has<br />

finished. An abort specifies that the current behaviour is interrupted but cannot be<br />

resumed. Alternative continuing behaviour can be specified.<br />

6.3.6.6 Interrupt with Reply Symbol<br />

During the work on our mailing machine case, the need <strong>of</strong> an additional symbol appeared.<br />

This symbol is a combination <strong>of</strong> an interrupt message flow and a message with

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!