For FreeRTOS tutorial suggestion: the xEventGroupSetBits() and xEventGroupWaitBits() API functions cannot be used (because of the non-atomic operation) if Task A, Task B and Task C attempt to synchronize using an event group. The xEventGroupSync() API Function is a good choice.
But for some other RTOS, there is no APIs like the xEventGroupSync(), and how can they solve this problem? Or can we solve this problem just use the the semaphor and event group instead of the xEventGroupSync() ?
First, this isn’t a “common” problem, and many programs just don’t need this form of syncing. More common is on task starts up a number of tasks and waits for them to finish,
Second, it is possible to write an equivalent operation with simpler primitives, it just isn’t as transparent what is going on, and the code may need to make assumptions about the code.
For instance, just having a lowest priority (lower than all the other tasks in the sync group) wait for all the other tasks to signal complete, and then it signaling to start the next group to all of them can duplicate the most common usage of this function, you just need a unique lowest priority task and you need to know which it is.
It needs to be lower than all of the other tasks so there is no actual race between them signaling they are done with the previous and then waiting on the event to start the next operation.
And the key to this solution is the priority of the additional task must lower than all the sync task.
In my opinion, the key to this problem is the event post/send operations in the task which is the last one enter the sync point is not atomic. May I use the critical section to make it uninterrupted?
So, the xEventGroupSetBits() will not wakeup the other pending task to clean the event.
After the last task call the xEventGroupSetBits(), the other 2 tasks become ready state but not runing. And the last task will not pend when call the xEventGroupWaitBits(). In this point, 3 tasks are all in ready state and start running after exit the critical section.
In general, you can’t ‘Wait’ (block) while in a critical section, so you have a problem there. It works in some ports but not others.
I suppose an interesting extension would be to allow waiting/blocking in a critical section which actually implies a “hole” in the critical section for the duration of the block, so you can know that you actually have reached the event wait.
I’m a bit confused by this discussion. FreeRTOS has the API xEventGroupSync() that solves this problem, as mentioned in the first post, so why have a discussion about how to do it without using that API?
Interested to know why you are writing a HAL, as other HALs already exist, maybe you want something universal. Is this something we should be interested in too - you can contact me privately at r dot barry at FreeRTOS dot org if it’s not something you wish to discuss here. You have highlighted the issue with HALs though - you only get the lowest common denominator - that is - exposing only the functionality the RTOSes have in common with no special source.
