# New Lab-Project-FreeRTOS-FAT Concurrency Problems

**URL:** <https://forums.freertos.org/t/new-lab-project-freertos-fat-concurrency-problems/14065>\
**Category:** Libraries\
**Created:** [December 15, 2021, 1:58am UTC](https://forums.freertos.org/t/new-lab-project-freertos-fat-concurrency-problems/14065 "2021-12-15T01:58:13Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![carlk3](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/carlk3/32/266_2.png) [@carlk3](https://forums.freertos.org/u/carlk3)\
**Post date:** [December 18, 2021, 5:55pm UTC](https://forums.freertos.org/t/new-lab-project-freertos-fat-concurrency-problems/14065/11 "2021-12-18T17:55:18Z")

</div>

> [@htibosch](#):
>
> I must admit that I fully agreed with mentioned changes to ff\_locking.c  
> The new code was shorter and more elegant.

Where I got confused was this sentence from [Mastering the FreeRTOS™ Real Time Kernel](https://www.freertos.org/fr-content-src/uploads/2018/07/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf), “The xEventGroupWaitBits() API Function”,

> The xClearOnExit parameter is provided to avoid these potential race conditions. If  
> xClearOnExit is set to pdTRUE, then the testing and clearing of event bits appears to the  
> calling task to be an atomic operation (uninterruptable by other tasks or interrupts).

The part that I missed is that

> [@xEventGroupWaitBits broken in FreeRTOS SMP?](https://forums.freertos.org/t/xeventgroupwaitbits-broken-in-freertos-smp/14075/6):
>
> When xEventGroupSetBits is called, EVERY task whose condition is now met is unblocked, and given the return code of the bits at that point, and THEN the bits are cleared if requested by any of the tasks.

`xEventGroupSetBits` is a single step, and one that unblocks all waiting tasks in this case. The fact that they all atomically clear the bit if `xClearOnExit` is `pdTRUE` doesn’t help because they’re all already running. So, a second atomic step, `xEventGroupClearBits`, is needed to select a winner and send the others back to `xEventGroupWaitBits`.

> [@htibosch](#):
>
> The above code made me think that the new method is also safe.

I agree, but it’s really the old, old method. I don’t know who wrote it in the first place, but they knew what they were doing (although I do wonder about the efficiency of this locking mechanism).

> [@htibosch](#):
>
> Now I wonder if the locking also shows problems when running on a single core. I will test that next week.

You mean, recreating the problem with the broken code on a single core? It is not easy to come up with good stress tests for this. Hard to get the timing right so that the first task doesn’t always proceed before there are any other waiters. With this particular bug, the problem only showed up when there was contention. Adding a [configASSERT](https://github.com/FreeRTOS/Lab-Project-FreeRTOS-FAT/pull/24/files#:~:text=configASSERT(pxIOManager%2D%3EpvFATLockHandle%20%3D%3D%20NULL)%3B) to `FF_LockFAT` helps with early detection.

---

_[View the full topic](https://forums.freertos.org/t/new-lab-project-freertos-fat-concurrency-problems/14065)._