Threads are a great mechanism to break-up an application into smaller, more manageable pieces. Once a developer starts to create threads in their application, it becomes necessary to figure out how to synchronize the threads. Not every thread will exist in a vacuum all by itself. In many instances, threads will work together to fulfill the system requirements. In this post, we will examine the synchronization objects available in ThreadX and when each should be used.


There are several objects within ThreadX that developers can use to synchronize threads and even communicate between them. These objects include:

  • Mutexes
  • Semaphores
  • Event Flags
  • Message Queues

Each object serves the purpose for synchronizing, event notification, mutual exclusion or inter-thread communication.


A mutex, is used to provide exclusive access (mutual exclusion) to a shared resource in the application. For example, if a developer has to share a UART or a memory location between multiple threads, a mutex can be used to allow a thread to take ownership of the resource. Once the thread has finished using the resource it then releases ownership so that other threads can use the resource.


A semaphore is used to provide synchronization between multiple threads. A semaphore is essentially a token that is given and taken. A semaphore can have just a single token, a binary semaphore, or multiple tokens depending on the application needs. A thread can be blocked if a semaphore is not available which then synchronizes it to another thread that gives the semaphores. A counting semaphore could be given every time a character comes across on a UART. A thread that waits for characters to be received would then take the semaphore and process the character once it became the highest priority thread.


Event flags are another synchronization method that use less memory and are faster than semaphores. An event flag is a single memory location where each bit represents an event that can occur in the system. Threads can block on the event. When the event occurs, the thread then continues to execute if the thread is the highest priority thread that is ready to execute. An example could be event flags that get set when a temperature value exceeds a specified high or low set point.


Message queues are used to pass data around the application from one thread to the next. For example, one thread might be designed to act as a gate keeper for the UART. The thread receives new characters through the UART and then sends them to a thread that processes the serial data via a message queue.


Creating thread synchronizations and transmitting messages is extremely easy to do with the Renesas Synergy™ Platform. Developers should first open their projects Synergy configurator and navigate to the threads tab. The synchronization methods are added through the thread objects view. First a developer should select the thread they want to create the object in. Next, in the thread objects view, clicking on the add arrow will reveal a menu with the available synchronization objects. A developer then can select the object they are interested in adding. This can be seen in the image below:



Developers can often become confused on when they should use each object in their application. The book “Multithreading using ThreadX®” has a great table that summarizes for developers when they should use each object. The summary can be found below:



Thread Synchronization

Event Notification

Mutual Exclusion

Inter-Thread Communication






Counting Semaphore

OK – better for one event




Event Flags Group





Message Queue





(Source: Multithreading using ThreadX® page 43)


In the next few posts, we will dive into each synchronization object in detail and explore how they can be used in the Synergy development environment. Until next time,


Live long and profit!





Hot Tip of the Week


Many of the more advanced application projects use RTOS objects for synchronization, notification and exclusion. The Audio Player Application, for example, uses queues and semaphores to enable communication between threads and control code execution without blocking the processor. The Audio Player application project can be found here: The associated application note can be found here: