pw_sync_threadx

Pigweed AI summary: The pw_sync_threadx is a set of backends for pw_sync based on ThreadX. It can be used without using the Pigweed provided pw_chrono_threadx in case the ThreadX time API is not available. The critical section lock primitives include Mutex and TimedMutex, which use TX_MUTEX as the underlying type. The InterruptSpinLock is backed by an enum class and two UINT, and uses tx_interrupt_control to enable critical sections. The signaling primitives include ThreadNotification and Timed

This is a set of backends for pw_sync based on ThreadX.

It is possible, if necessary, to use pw_sync_threadx without using the Pigweed provided pw_chrono_threadx in case the ThreadX time API (tx_time_get())) is not available (i.e. TX_NO_TIMER is set). You are responsible for ensuring that the chrono backend provided has counts which match the ThreadX tick based API.

Critical Section Lock Primitives

Pigweed AI summary: The ThreadX backend for critical section lock primitives includes Mutex and TimedMutex, which use TX_MUTEX as the underlying type and are created and cleaned up using tx_mutex_create and tx_mutex_delete. The InterruptSpinLock is backed by an enum class and two UINT, which detect accidental recursive locking and unlocking contexts. It uses tx_interrupt_control to enable critical sections and tx_thread_preemption_change to prevent accidental thread context switches while held by a thread. However, this backend does not yet support SMP due to

Mutex & TimedMutex

Pigweed AI summary: The Mutex and TimedMutex in ThreadX use TX_MUTEX as the underlying type, created with tx_mutex_create and cleaned up with tx_mutex_delete in the constructors and destructors.

The ThreadX backend for the Mutex and TimedMutex use TX_MUTEX as the underlying type. It is created using tx_mutex_create as part of the constructors and cleaned up using tx_mutex_delete in the destructors.

InterruptSpinLock

Pigweed AI summary: The InterruptSpinLock in ThreadX is supported by an enum class and two UINT objects to prevent accidental recursive locking and unlocking contexts. It uses tx_interrupt_control to enable critical sections and tx_thread_preemption_change to prevent accidental thread context switches. However, this backend does not support SMP yet as there is no internal lock to spin on.

The ThreadX backend for InterruptSpinLock is backed by an enum class and two UINT which permits these objects to detect accidental recursive locking and unlocking contexts.

This object uses tx_interrupt_control to enable critical sections. In addition, tx_thread_preemption_change is used to prevent accidental thread context switches while the InterruptSpinLock is held by a thread.

Warning

This backend does not support SMP yet as there’s no internal lock to spin on.

Signaling Primitives

Pigweed AI summary: The article discusses signaling primitives in ThreadX API and recommends using binary semaphore backends for ThreadNotifications. It also explains why using tx_thread_sleep and tx_thread_wait_abort cannot work for direct thread notifications due to a race condition. Additionally, the article mentions the use of TX_SEMAPHORE as the underlying type for ThreadX backends for BinarySemaphore and CountingSemaphore.

ThreadNotification & TimedThreadNotification

Pigweed AI summary: The ThreadX API does not cover direct thread signaling, so it is recommended to use binary semaphore backends for ThreadNotifications. Using tx_thread_sleep and tx_thread_wait_abort to implement direct thread notifications with ThreadX will not work due to a race condition between setting the thread handle and executing tx_thread_sleep.

The native ThreadX API does cover direct thread signaling and ergo we recommend using the binary semaphore backends for ThreadNotifications: - pw_sync:binary_semaphore_thread_notification_backend - pw_sync:binary_semaphore_timed_thread_notification_backend

Background Information

Pigweed AI summary: Using tx_thread_sleep and tx_thread_wait_abort to implement direct thread notifications with ThreadX is not possible due to a race condition that exists between the blocking thread setting its TX_THREAD* handle and executing tx_thread_sleep. This means that another thread or interrupt may attempt to invoke tx_thread_wait_abort before the blocking thread has executed tx_thread_sleep, causing the wait abort to fail.

Although one may be tempted to use tx_thread_sleep and tx_thread_wait_abort to implement direct thread notifications with ThreadX, this unfortunately cannot work. Between the blocking thread setting its TX_THREAD* handle and actually executing tx_thread_sleep there will always exist a race condition. Another thread and/or interrupt may attempt to invoke tx_thread_wait_abort before the blocking thread has executed tx_thread_sleep meaning the wait abort would fail.

BinarySemaphore & CountingSemaphore

Pigweed AI summary: The ThreadX backends for BinarySemaphore and CountingSemaphore use TX_SEMAPHORE as the underlying type, created with tx_semaphore_create in the constructor and cleaned up with tx_semaphore_delete in the destructor.

The ThreadX backends for the BinarySemaphore and CountingSemaphore use TX_SEMAPHORE as the underlying type. It is created using tx_semaphore_create as part of the constructor and cleaned up using tx_semaphore_delete in the destructor.