Components can have in or out bindings propagations. In E.7, Semantics (7), the standard says, "The keyword bindings is used in execution platform components to identify the binding point of all components bound to them." For example, if a processor has an out bindings propagation, then that processor can propagate errors to all threads bound to it by the property Actual_Processor_Binding.
However, it is possible for certain components to be the targets of multiple kinds of bindings. In the following example, the processor proc is the target for a processor binding, a memory binding, a connection binding, and a function binding:
package StandardIssue
public
system s
end s;
system implementation s.i
subcomponents
proc: processor proc;
ps: process ps.i;
vb: virtual bus vb;
subp: subprogram subp;
properties
Actual_Processor_Binding => (reference (proc)) applies to ps.t;
Actual_Memory_Binding => (reference (proc)) applies to ps.t.d;
Actual_Connection_Binding => (reference (proc)) applies to vb;
Actual_Function_Binding => (reference (proc)) applies to subp;
end s.i;
abstract proc
annex EMV2 {**
use types ErrorLibrary;
error propagations
bindings: in propagation {ServiceError};
bindings: out propagation {ServiceError};
end propagations;
**};
end proc;
process ps
end ps;
process implementation ps.i
subcomponents
t: thread t.i;
end ps.i;
thread t
annex EMV2 {**
use types ErrorLibrary;
error propagations
processor: in propagation {ServiceError};
processor: out propagation {ServiceError};
end propagations;
**};
end t;
thread implementation t.i
subcomponents
d: data d;
end t.i;
data d
annex EMV2 {**
use types ErrorLibrary;
error propagations
memory: in propagation {ServiceError};
memory: out propagation {ServiceError};
end propagations;
**};
end d;
virtual bus vb
annex EMV2 {**
use types ErrorLibrary;
error propagations
connection: in propagation {ServiceError};
connection: out propagation {ServiceError};
end propagations;
**};
end vb;
subprogram subp
annex EMV2 {**
use types ErrorLibrary;
error propagations
binding: in propagation {ServiceError};
binding: out propagation {ServiceError};
end propagations;
**};
end subp;
end StandardIssue;
The way that the standard is currently written, a ServiceError raised in proc would be propagated to ps.t, ps.t.d, vb, and subp. There is no way to restrict a bindings propagation to be only for processor bindings or only for memory bindings. Is this intentional? Is the desirable? Do we want to be able to model that an error propagates out via processor bindings and connection bindings, but not memory bindings nor function bindings?
Components can have in or out
bindings
propagations. In E.7, Semantics (7), the standard says, "The keyword bindings is used in execution platform components to identify the binding point of all components bound to them." For example, if a processor has an outbindings
propagation, then that processor can propagate errors to all threads bound to it by the propertyActual_Processor_Binding
.However, it is possible for certain components to be the targets of multiple kinds of bindings. In the following example, the processor
proc
is the target for a processor binding, a memory binding, a connection binding, and a function binding:The way that the standard is currently written, a
ServiceError
raised inproc
would be propagated tops.t
,ps.t.d
,vb
, andsubp
. There is no way to restrict abindings
propagation to be only for processor bindings or only for memory bindings. Is this intentional? Is the desirable? Do we want to be able to model that an error propagates out via processor bindings and connection bindings, but not memory bindings nor function bindings?