I have been quite excited about the new event group feature. There have been quite a few occasions where I found that I had a task that needed to block on multiple signals and the event groups look to be the answer for this.
However I have a question regarding the design decision of xEventGroupSetBitsFromISR (and xEventGroupClearBitsFromISR?). The documentation states:
Setting bits in an event group is not a deterministic operation because there are an unknown number of tasks that may be waiting for the bit or bits being set. FreeRTOS does not allow non-deterministic operations to be performed in interrupts or from critical sections. Therefore xEventGroupSetBitFromISR() sends a message to the RTOS daemon task to have the set operation performed in the context of the daemon task - where a scheduler lock is used in place of a critical section.
I was wondering if this is a technical issue or more of a design philosophy issue. If it is the former, then perhaps a more detailed explanation might be helpful, however if it is the latter then I have trouble accepting this for the following reasons:
- The event groups are essentially like a group of semaphores and so the same reasoning could be applied to semaphores (there are an unknown number of tasks that may be waiting for the semaphore to be given). Why are semaphores treated differently in the context of an interrupt when their use is so similar?
- The implementation requires the use of an additional task and related overhead, which is otherwise unnecessary (well in my case it isn’t necessary).
- xEventGroupSetBitsFromISR can fail to register the request which in my opinion makes it not deterministic and therefore defeating the purpose of the chosen design. Unlike a semaphore, it is unsuitable for use in an interrupt service routine because it cannot be relied upon to always be able to set the bit(s) and potentially unblock any task that is waiting for the bit(s).
I wanted to use the event group mechanism for monitoring some “data request” inputs from several mp3 decoder ICs. Basically the idea was to have a single interrupt service routine and a single event group and just set or clear the bits depending on the state of the data request pins. Separate tasks for each mp3 decoder would then wait for their appropriate bit to be set before proceeding and also stop sending data to its decoder when the appropriate bit was cleared. However because of issue (3) above, I decided that the mechanism was unreliable and would lead to errors. I was also unimpressed by the additional overhead and decided that it wasn’t worthwhile.