Asynchronous Thread

Executes a Function Call Subsystem in an asynchronous thread.

Library

Description

The Asynchronous Thread block executes the Function Call Subsystem attached to its output in an asynchronous thread. The thread is initialized at model start, but does not begin to run until the first execution of the Asynchronous Thread block to ensure that the entire model is initialized prior to any subsystems running. Thus, if the Asynchronous Thread block is placed in a conditionally executed subsystem then the thread will not begin to run until that subsystem executes for the first time.

The Asynchronous Thread block supports two different modes: one-shot mode and repetitive mode. In either mode, the Asynchronous Thread block creates a thread at model start. That thread then waits for a signal from the Asynchronous Thread block before executing the Function Call Subsystem attached to the output.

In one-shot mode, the asychronous thread is signalled the first time the Asynchronous Thread block executes. The asynchronous thread wakes up, runs the Function Call Subsystem to completion and then exits. The asynchronous thread is not run repeatedly and has no associated sample rate. If the model is terminated prior to the completion of the asynchronous thread then the model will cancel the asynchronous thread and wait until the asynchronous thread completes before it exits.

In repetitive mode, the asychronous thread is signalled every time the Asynchronous Thread block executes. For each signal sent, the asynchronous thread wakes up, runs the Function Call Subsystem and then waits for another signal from the Asynchronous Thread block. Thus, each time the Asynchronous Thread block executes, the associated Function Call Subsystem is run in the asynchronous thread. If the model is terminated prior to the completion of the asynchronous thread then the model will wait until the asynchronous thread completes before it exits. The asynchronous thread will complete as soon as the Function Call Subsystem has completed its execution. It will not wait for another signal from the Asynchronous Thread block.

The repetitive mode is a convenient way to create a "worker" thread that performs a task asynchronously to the rest of the model upon request. For example, if the Asynchronous Thread block is placed in a Triggered Subsystem then the asynchronous thread will run its associated Function Call Subsystem each time the Triggered Subsystem is triggered. If the asynchronous thread is configured to have a lower priority than the base rate task of the model then the thread will be preempted when necessary by the base rate task and will not interfere with its execution. This mechanism allows event-driven operations that would be too slow to handle at the base rate to be handled in a separate thread instead. The priority of the base rate of the model is configured using the Minimum thread priority field of the QUARC tab of the Code Generation pane of the Configuration Parameters dialog.

Signals transferred between the asynchronous Function Call Subsystem and the periodic tasks of the model generally require one of the Protected RT or Unprotected RT rate transition blocks to ensure that data is transferred correctly between periodic and asynchronous tasks. More advanced techniques, such as FIFO queues, are available using the other blocks in the Asynchronous library.

In normal simulation the Asynchronous Thread block does not spawn a separate thread because the Simulink engine does not support multiple threads. Instead, if the Active during normal simulation option is checked, it executes the Function Call Subsystem in the same thread as the rest of the simulation. Hence, the Function Call Subsystem will run to completion before the rest of the simulation continues. In real-time code, of course, the Function Call Subsystem is run concurrently with the periodic tasks in the diagram so this difference in behaviour must be taken into account when performing simulations. In one-shot mode the Function Call Subsystem will only be called once, the first time the Asynchronous Thread executes. In repetitive mode, it will be called every time the Asynchronous Thread executes.

Any number of Asynchronous Thread blocks may be placed in the diagram. This block may not be placed in a referenced model because model referencing does not currently support asynchronous blocks.

Limitations

Sinks blocks such as Display and Scope blocks are not supported in external mode within asynchronous subsystems like the Function Call Subsystem attached to the Asynchronous Thread block. In fact, their presence can cause Simulink to crash in external mode. This limitation is a characteristic of Simulink, not the generated code. To display the values of signals from an asynchronous subsystem, use the FIFO Write and FIFO Read blocks, or one of the Rate Transition blocks such as the Protected RT block, to transfer the signals to a periodic task and display their value from the periodic task.

Input Ports

This block has no input ports.

Output Ports

This block has a single output port to which a Function Call Subsystem should be attached. If the output is left unconnected then no code is generated for this block.

Parameters and Dialog Box

Asynchronous mode

Determines the semantics of the block. In one-shot mode the Function Call Subsystem is executed in a separate thread the first time the Asynchronous Thread block is run. In repetitive mode the Function Call Subsystem is executed in a separate thread every time the Asynchronous Thread block is run.

Priority (tunable offline)

The priority of the thread. In general, a value of 0 indicates the lowest priority and higher values indicate a higher priority. The number of priority levels available depends on the type of QUARC target for which code is being generated.

Stack size (tunable offline)

The stack size to use for the thread. Specifiy a value of 0 to use the default stack size for the QUARC target. The minimum stack size depends on the type of QUARC target for which code is being generated.

CPU affinity (tunable offline)

The set of CPUs upon which the thread may run. Specify a value of [] to allow the thread to run on any CPU. To restrict the thread to a set of CPUs enter a vector of CPU numbers, where CPUs are numbered from zero to one less than the number of CPUs available.

Sample time

The sample time of the block. A sample time of 0 indicates that the block will be treated as a continuous time block. A positive sample time indicates that the block is a discrete time block with the given sample time.

A sample time of -1 indicates that the block inherits its sample time. Since this is a source block, only inherent the sample time when it is placed in a conditionally executed subsystem, like a Triggered or Enabled Subsystem.

The default sample time is set to qc_get_step_size, which is a QUARC function that returns the fundamental sampling time of the model. Hence, the default sample time is a discrete sample time with the same sampling time as the fixed step size of the model.

Note that the sample time applies to the Asynchronous Thread block only, which executes like any other block in the diagram. The sample time does not apply to the Function Call Subsystem attached to the output, which is executed in an aperiodic, asynchronous thread.

Targets

See Also

• Asynchronous Threads
• Rate Transition block

Copyright ©2024 Quanser Inc. This page was generated 2024-10-17. Submit feedback to Quanser about this page.

Link to this page.