Summary
This table summarizes the information covered in this lesson. The Level of Determinism column of the table gives a rough indication of the certainty that the corresponding primitive will happen at the set time limit.
| Primitive | Features | Intended Use | Level of Determinism | Example |
|---|---|---|---|---|
| Preemptible thread | – An isolated logical unit with its own stack. | – Application code | High | In both Exercise 1 and Exercise 2 of this lesson, the threads used are preemptible threads. In application code: The vast majority of nRF Connect SDK samples and applications use preemptible threads. In subsystems: The logger module in deferred mode is implemented as a preemptible thread. |
| Cooperative thread | – Can’t be preempted by other threads*. Run until the thread decides on its own to stop running. – Enforce scheduler locking. | – Subsystems and network stacks – Device drivers – Some corner cases of application code with performance-critical work | High | In the Kernel: The system work queue is implemented as a cooperative thread In application code: Multiprotocol Service Layer (MSPL) timeslot sample. In driver Code: The Bluetooth LE HCI drivers. |
| System workqueue | – Lightweight. Work items share one stack, which is the system workqueue stack. – The system workqueue is created by the kernel itself and used in various subsystems. | – Subsystems, device drivers – Delegating lengthy tasks from interrupt context to thread context. – lightweight non-blocking application code . | Moderate | In subsystems: The Bluetooth LE stack uses the system workque in different use cases, as does the MCUmgr, among many other subsystems. Delegating lengthy tasks from ISR to thread context (for example, the bh1749 driver). In application code: In the Central HID sample. |
| User workqueue | – Lightweight. Work items share one stack which is the workqueue stack. – Advantage of the user workqueue vs the system workqueue is that the queue is not shared with the other subsystems in the firmware, which makes task scheduling more deterministic. | – Application code – Subsystems can also create their own user workqueue – Delegating lengthy tasks from interrupt context to thread context. | Above moderate | Lesson 7 – Exercise 3 of the nRF Connect SDK Fundamentals course focuses on the user workqueue. In application code: Wi-Fi Provisioning sample, MQTT networking sample. In subsystems: The Network TCP stack creates it’s own user workqueue. |
| Meta-IRQ | – A special class of cooperative threads that can preempt other threads, including cooperative threads. | – Intended for device drivers’ “bottom half” workload | Very high | Bluetooth LE stack |
| Regular ISR | – Completely asynchronous. | – For device drivers – Some case of application code where high determinism is required (the application code here must be non-blocking) | Extremely high | Almost all drives have interrupts. For example, nRF700X Wi-Fi driver. |
| Direct ISR | – Completely asynchronous. – Suitable for low-latency use cases, where less overhead is desired. – Less overhead than a regular ISR, but a reduced feature set. – More restricted access to Kernel services | – For device drivers | Highest | Some special drivers, such as the timers and radios. For example, Link Layer Controller for Bluetooth LE. |
*Meta-IRQ threads (if one exists) can preempt a cooperative thread, but the execution is guaranteed to return to the cooperative thread preempted.
