![]() ![]() |
||||
|
||||
A data subprogram feature represents an execution entrypoint
in source text that operates on a
data component of the associated data type. Server subprogram features represent entrypoints for
remote procedure calls, i.e., the ability to synchronously call this subprogram from a separate
thread that may execute on a different processor.
Syntax
data_subprogram_spec ::=
defining_subprogram_identifier
: subprogram
[ subprogram_classifier_reference
]
[ {
{ subprogram_property_association }+ } ] ;
data_subprogram_refinement ::=
defining_subprogram_identifier :
refined to subprogram
[subprogram_classifier_reference
]
[ {
{ subprogram_property_association }+ } ] ;
server_subprogram_spec ::=
defining_subprogram_identifier
: server subprogram
[
unique_subprogram_reference ]
[ { { subprogram_property_association
}+ } ] ;
server_subprogram_refinement ::=
defining_subprogram_identifier
: refined to
server subprogram
[
unique_subprogram_reference ]
[ { { subprogram_property_association
}+ } ] ;
unique_subprogram_reference ::=
subprogram_classifier_reference
| data_subprogram_feature_classifier_reference
data_subprogram_feature_classifier_reference
::=
[ package_name ::
] data_type_identifier . subprogram_identifier
Naming Rules
A unique subprogram reference must be a subprogram classifier
reference or a reference to a
subprogram feature declaration in a data component type.
Legality Rules
Data subprogram features can be declared in data components
and must not have the reserved
word server.
Server subprogram features can be declared in thread,
thread group, process, processor, and
system component types. They must have the reserved word server.
A server subprogram feature declaration must only refer
to a subprogram classifier or to a
subprogram feature in a data component type.
If several subprogram declarations refer to the same
subprogram type or via the Source_Name
property to the same subprogram in the source text, then their parameter signatures in the source
text and the property associations must be consistent with each other.
When a server subprogram declaration appears in a thread
component type, the scheduling
protocol property value for all thread implementations, subcomponents, and instances having that
component type must be Aperiodic or
Sporadic.
A subprogram refinement can specify a subprogram type
reference and declare property
associations.
For calls to server subprograms, the subprogram classifier
or subprogram feature reference of the
subprogram call and the subprogram classifier or subprogram feature reference of the server
subprogram must be the same.
Standard Properties
Source_Name: aadlstring
Source_Text: inherit list
of aadlstring
Source_Stack_Size: Size
-- Subprogram execution properties
Subprogram_Execution_Time: Time_Range
-- Client subprogram execution properties
Client_Subprogram_Execution_Time: Time
-- Server subprogram execution properties
Compute_Execution_Time: Time_Range
Compute_Deadline: Time
Recover_Execution_Time: Time_Range
Recover_Deadline: Time
Overflow_Handling_Protocol: enumeration (DropOldest,
DropNewest, Error)
=>
DropOldest
Queue_Size: aadlinteger 0 ..
value(Max_Queue_Size) => 0
Semantics
Data subprogram features represent entrypoints into source
text that operate on data components
of the associated data component type. They are called by naming a data component type and
the subprogram separated with a . (dot) (see also Section 5.2).
Data subprogram features can refer to separately declared
subprogram classifiers, which may
specify the parameters, required access, and out event or out event data ports of the subprogram
(see Section 5.2).
If server subprogram features refer to subprograms in
source text with parameters, the parameters
are marshalled and unmarshalled as necessary.
If server subprogram features refer to subprograms that
raise events or event data, then the raised
event in the server subprogram is mapped to the corresponding event or event data port in the caller
subprogram.
Threads and subprograms can contain subprogram calls
(see Sections 5.2 and 5.3). These can be
calls to subprograms local to thread, or they can be synchronous remote calls to a server
subprogram in another thread that is indicated by the Actual_Subprogram_Call property. In
case of a remote call, the requesting thread calls a local proxy that carries out the service request.
The execution time of the client proxy is determined by the
Client_Subprogram_Execution_Time.
The actual call results in communicating the
subprogram execution request. While the call is in progress, the calling thread is blocked.
Upon
completion of the remote subprogram execution and return of results, the calling thread resumes
execution by entering the ready state.
Server subprogram features model service requests such
as remote procedure calls to services
provided by a thread. Actual calls are specified as explicit subprogram calls whose call binding
property specifies a server subprogram.
Server subprogram features can be declared with their
signature defined in the referenced and
separately declared subprogram classifiers.
A server subprogram feature declaration in a thread component
type represents an entrypoint to a
remotely callable code sequence in the source text associated with a different thread. This thread
may reside in the same process, a different process on the same processor, or on a different
processor. A request for execution of such a subprogram is a dispatch request to the thread
containing the server subprogram the same way events represent dispatch requests for aperiodic
or sporadic threads. As in the case of events, requests for execution of server subprograms may
be queued if the thread is already executing a dispatch request. A thread can have multiple
subprogram entrypoints, expressed by multiple server subprogram feature declarations in the
respective component type. Only one of these server subprograms may be executed per thread
dispatch. Queuing and queue servicing follows the semantics of event port queues.
If an event is raised during the execution of a server
subprogram, this event is communicated back
to the calling subprogram and propagated according to the connection declaration associated with
the event port of the caller (see also Section 5.3).
If an error occurs or is raised while the thread is executing
the server subprogram, that error is
communicated through the Error
port of the containing thread - as previously defined in Section
5.3.
Processing Requirements and Permissions
Every method for processing specifications must parse
subprogram feature declarations and check
the legality rules defined in this standard. However, a method of processing specifications need
not define how to build a system from a specification that contains subprogram features. In this
case, subprogram features may be rejected as unsupported. In this case, a warning message may
be generated to notify the user of this behavior in the toolset.
A subprogram feature of a software component maps to
a subprogram declared in associated
source text as defined in the source language annex of this standard. This source subprogram
must be declared and visible at the outermost lexical scope as defined by the applicable source
language standard. The parameter identifiers appearing in the subprogram feature declaration must
map to formal parameter names appearing in the source subprogram declaration. Rules for
mapping subprogram and parameter identifiers to source text are defined in the source language
annex of this standard. Any special rules for server subprograms and parameter are defined in
the
source language annex of this standard.
A call to a server subprogram feature of a software component
maps to a call to the proxy for the
remote subprogram in the associated source text. This proxy routine performs the appropriate
remote invocation. Actual calls to the proxy subprogram in the source text are found in the source
program of the calling thread. The data types of the actual parameter expressions must be
compatible with the declared data types in the specification as defined by the applicable source
language standard. The details of these mappings are defined in the source language annex of this
standard.
A method of implementation may automatically generate
the source text required to perform a
remote subprogram call. This may include the marshalling and unmarshalling parameter values or
the transmission and reception of call and return events.
If the calling thread can execute on the same processor
as the server subprogram, then a method
of implementation may use the calling thread to execute the server subprogram code rather than a
separate thread. When using this optimization procedure, proper synchronization must be
maintained to preserve the same runtime semantics. If runtime address space protection is
required, then this technique cannot be used if the protection between the calling thread and server
subprogram thread is lost as result of the optimization.
NOTES:
The annex subclause may
be used along with the existing syntax to build a component-based
client/server subprogram model. An example of this approach follows.
Examples
package Pierre
public
process printers
features
printonServer
: server subprogram print;
mainPrinter: in
event port;
backupPrinter: in
event port;
end printers;
process implementation
printers
subcomponents
A : thread
printer in modes ( modeA );
B : thread
printer in modes ( modeB );
Modes
modeA: initial
mode;
modeB: mode;
modeA -[ backupPrinter ]->
modeB;
modeB -[ mainPrinter ]->
modeA;
end printers;
thread printer
features
print
: server subprogram print;
end printer;
subprogram print
features
filetoprint:
data file;
end print;
end Pierre;
thread A
features
print: requires subprogram
Pierre::print;
calls
print: subprogram;
end A;
-- example of a server subprogram call
process B
annex pierre {**
-- a new features declaration to indicate
a required subprogram
features
remoteprint: requires
subprogram Pierre::print;
**}
end B;
-- example of a local subprogram call
-- the subprogram is locally declared
within the process.
-- the call is bound to it.
process C
end C;
process implementation C.default
subcomponents
app: thread A;
annex pierre {**
-- a new subcomponents declaration
to specify a local subprogram
subcomponents
localprint: subprogram
Pierre::print;
-- a new connection declaration
to bind a required subprogram to a
-- local subprogram or
a server subprogram via connections
connections
subprogram app.print
-> localprint;
**}
end C.default; |
||||