This defines a dependency for a task or family. There can be only one trigger dependency per node, but that can be a complex boolean expression of the status of several nodes. Triggers should be avoided on suites.
A node with a trigger can only be activated when its trigger has expired. A trigger holds the node as long as the trigger's expression evaluation returns false. There are a few additional keywords and some names may point to other nodes with their value acting as the status of those nodes. Trigger mathematics are computed, using double arithmetic (with no string comparisons). There should not be any need to use numerical expressions, instead logical functions (and, or, not, eq, ne) with node names should be used.
The keywords in trigger mathematics are: unknown, suspended, complete, queued, submitted, active and aborted for task and family status; and clear and set for event status. These keywords are treated as numbers starting from 0 (unknown) to 6 (aborted). There is no need to be aware of the numerical values as long as you do not use a trigger in the form:
trigger plain_name # WARNING! DO NOT USE!
This is true only as long as the status of plain_name is unknown. It is not advisable to use mathematical function names for node names.
The full name or relative name of a node can also be used as an operand. A full name starts from the super-node. A relative name can include "../" to indicate the parent node level. A relative name can also include "./' to indicate the same level, this is needed if the task name is numeric (otherwise its numeric value would be used in the expression.)
| Code Block |
|---|
family foo task bar task foobar endfamily family second task 00z trigger ../foo/foobar==complete # task from previous family task another trigger ./00z == complete # the previous task |
...
| Code Block |
|---|
task foo
meter hour 0 240
task bar
trigger foo:hour >= 120
task foobar
trigger foo:hour == 120 # dangerous !!!
|
There
...
is
...
no
...
automatic
...
checking
...
for
...
deadlocks,
...
which can be difficult to detect. However, if your suite is known to complete (i.e.
...
it does
...
not
...
run
...
forever),
...
then
...
simulation
...
can
...
be
...
used
...
to
...
check
...
for
...
deadlocks.
...
The
...
following
...
example
...
is
...
a
...
simple
...
case:
| Code Block |
|---|
task a ; trigger ./b == complete
task b ; trigger ./a == complete # DEADLOCKS tasks a & b |
...
| Code Block |
|---|
trigger /suite/family1/task1==complete and ( /suite/family2 \ eq complete or /suite/family3 eq complete ) |
There cannot be any characters after the line continuation character `\'; any keyword can appear in an expression but they must be used in a way that makes sense. For example, a task can never be set or clear and, likewise, an event can only be set or clear.Anchor
See section 5.3.6 on externs for details on using triggers external to the suite.