Section 13.1

LRM-23

Changes (change in red):

Semaphores and mailboxes are built-in types, nonetheless, they are classes, and can be used as base classes for deriving additional higher level classes. Built-in classes reside in the built-in namespace (see Section 7.10.1), thus, they may be re-defined by user code in any other scope.

Section 13.4

LRM-37

Changes (change in red):

The only difference between a generic (dynamic) mailbox and a parameterized mailbox is that for a parameterized mailbox, the compiler ensures that all the put, try_put, peek, try_peek and, get, and try_get methods are compatible with the mailbox type, so that all type mismatches are caught by the compiler and not at run-time.

Section 13.5.3

LRM-18

Changes (change in red):

The basic mechanism to wait for an event to be triggered is via the event control operator, @.

@ hierarchical_event_identifier event_identifier;

The @ operator blocks the calling process until the given event is triggered.

Section 13.5.4

LRM-18

Changes (change in red):

The triggered property is invoked using a method-like syntax:

hierarchical_event_identifier.triggered event_identifier.triggered

The triggered event property evaluates to true if the given event has been triggered in the current time-step

and false otherwise. If event_identifier is null, then the triggered event property evaluates to false.

The triggered event property is most useful when used in the context of a wait construct:

wait ( hierarchical_event_identifier.triggered event_identifier.triggered )