# Event Group clarification **URL:** \ **Category:** Kernel\ **Created:** [November 4, 2019, 7:42am UTC](https://forums.freertos.org/t/event-group-clarification/8149 "2019-11-04T07:42:59Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 4, 2019, 7:42am UTC](https://forums.freertos.org/t/event-group-clarification/8149/1 "2019-11-04T07:42:59Z")
**[sasikalaswathi](https://sourceforge.net/u/sasikalaswathi/)** wrote on [Monday, November 04, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/db04945807/#90a5): Created the event group with one set\_task and 3 read\_bits\_tasks. vEventBitSettingTask which sets the bit 0,bit 1 and bit 2. vEventBitReadingTask -wait to read the bit 0 vEventBitReadingTask1 -wait to read the bit 1 vEventBitReadingTask 2-wait to read the bit 2 All tasks are same priority. Here are the things which needs clarfication. 1. Irrespective of setting and waiting for the bits to set , all tasks will run until particular time slice expires(Switch between tasks of equall priority will occur on every tick interrupt)? but in API xEventGroupSetBits, Setting bits in an event group will automatically unblock tasks that are blocked waiting for the bits. While checking the output via printf, i get the following output: Setting bit task output - AFTER BIT 0 set AFTER BIT 1 set: AFTER BIT 2 set AFTER BIT 0 set AFTER BIT 1 set: AFTER BIT 2 read\_bit task output: bit 0 was set bit 1 was set bit 2 was set While saw the output, the task which setting the bits (bit 0, bit 1, bit 2) will executes again even after the bit set right? here after one iteration of event bit set, control will not automatically unblock tasks that are blocked waiting for the bits. 1. In second case, i slightly change the tasks vEventBitSettingTask,vEventBitSettingTask1 and vEventBitSettingTask2 to wait for the same bit (bit 0) .Here the parameter of xClearOnExit set to pdTRUE. As a result, only one task( vEventBitSettingTask) get the chance to read the bits. In other reader tasks(vEventBitSettingTask1 and vEventBitSettingTask2), the value resultant event group value was 0. Here to get the chance to all reader tasks which waited for one of the bit to set, I changed the value of xClearOnExit to following value vEventBitSettingTask - xClearOnExit-pdFALSE vEventBitSettingTask 1- xClearOnExit-pdFALSE vEventBitSettingTask2 - xClearOnExit-pdTRUE In that case, i get the following output, bit 0 -vEventBitReadingTask - first reader output string bit 0 -vEventBitReadingTask bit 0 -vEventBitReadingTask bit 0-vEventBitReadingTask1-second reader output string bit 0-vEventBitReadingTask1 bit 0-vEventBitReadingTask1 bit 0-vEventBitReadingTask2-third reader output string Is this the correct way to do? for all reader tasks get the chance to read the set bit / any other way to attain this? Attached the code for reference. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 4, 2019, 10:52am UTC](https://forums.freertos.org/t/event-group-clarification/8149/2 "2019-11-04T10:52:20Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 04, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/db04945807/#a832): Sorry - not following exactly, need to re-read with a bit more time to study. Hopefully the following will at least start to answer your questions. If you set a bit that multiple tasks are waiting for then all the tasks will get unblocked. If the unblocked task has a higher priority than the task that set the bit then the unblocked task will run immediately, so the context switch/preemption is immediate. If the unblocked task has the same priority then the context switch will not happen immediately but when the next tick occurs. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 4, 2019, 12:10pm UTC](https://forums.freertos.org/t/event-group-clarification/8149/3 "2019-11-04T12:10:53Z")
**[sasikalaswathi](https://sourceforge.net/u/sasikalaswathi/)** wrote on [Monday, November 04, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/db04945807/#a832/3bf8): Hi Richard, Thank you for the response. From your reply, I got answered for the first question. - If the unblocked task has a higher priority than the task that set the bit then the unblocked task will run immediately, so the context switch/preemption is immediate\* For this case, I set the priority of task (which wait for the particular bit to set) to higher than task which actually sets the bit. In this case, the task which setting the bit doesn’t get the chance to set the bit because of the reader task(wait for the particular bit) has higher priority. Do we have to manually introduce the delay (vTaskDelay) in reader task in order to set task get the priority? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [November 4, 2019, 12:14pm UTC](https://forums.freertos.org/t/event-group-clarification/8149/4 "2019-11-04T12:14:23Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, November 04, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/db04945807/#a832/3bf8/abe0): Normally the task would block reading the bit, so the lower priority task would be able to run and set the bit. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [November 4, 2019, 12:28pm UTC](https://forums.freertos.org/t/event-group-clarification/8149/5 "2019-11-04T12:28:54Z")
**[sasikalaswathi](https://sourceforge.net/u/sasikalaswathi/)** wrote on [Monday, November 04, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/db04945807/#a832/3bf8/abe0/8212): Thanks Richard, I found the problem, i set the xTicksToWait parameter of xEventGroupWaitBits to zero. Now i changed to higher value results in set bit task get the chance to run. ``` One more thing needs a confirmation: set_bit_task has lower priority than the read_bit_task. In that case purpose of set_bit_task to set two bits. First bit set(bit 0) causes the reader task(higher priority, waiting for only bit 0) to unblock. Here unblock occurs immediately with setting the remaining bit (say bit 1) / without setting the remaining bit to set? ```