# Receive more items from queue as sent to it **URL:** \ **Category:** Kernel\ **Created:** [December 19, 2022, 7:01am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416 "2022-12-19T07:01:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![hansfrick](https://avatars.discourse-cdn.com/v4/letter/h/b2d939/32.png) [@hansfrick](https://forums.freertos.org/u/hansfrick)\ **Post date:** [December 19, 2022, 7:01am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/1 "2022-12-19T07:01:42Z")
Hi, I use freeRTOS V10.4.3. I have un unexpected behavior with a queue. In an interrupt routine (r\_elc\_isr\_port1) I send an item to a queue (EventQueue) by xQueueSendToBackFromISR. In a task (cDigitalInputPwmTask::run) I receive the item from the queue with xTicksToWait = portMAX\_DELAY. I expect that xQueueReceive is blocked as long as no items are entered into the queue. I added counters to see if this true in my case. The FillCount counter is incremented, each time an item is sent to the queue and decrement each time an item is received from the queue. To be sure that the queue does not get full and items are not put to the queue i check with FullCount coounter. What I find is thet the FillCount gets negatic after a while and grows slowly into more negativ. The FullCount stays zero (as expected, queue has size of 50 items and at the most less than 10 are in the queue at a time). Than I added the additional EmptyCount counter after the call of xQueueReceive, to make sure, that the xQueueReceive only unblockes when their is an item in it. Thsi counter also stays zero. I attached the source file doing all described above. [DigitalInputPwmTask.cpp](https://forums.freertos.org/uploads/short-url/1PqqLRh5TLsX9UK5XRIOKdUpbCE.cpp) (7.0 KB) Has anyone an idea what can be wrong? Hans ---
**Author:** ![Shub](https://avatars.discourse-cdn.com/v4/letter/s/6f9a4e/32.png) [@Shub](https://forums.freertos.org/u/Shub)\ **Post date:** [December 19, 2022, 8:08am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/2 "2022-12-19T08:08:46Z")
A few observations in the code: 1. The fillcount is defined as int “int FillCount;”. Usually, “unsigned int” is used for counters. 2. There is equal to zero check when the count is decremented. ---
**Author:** ![hansfrick](https://avatars.discourse-cdn.com/v4/letter/h/b2d939/32.png) [@hansfrick](https://forums.freertos.org/u/hansfrick)\ **Post date:** [December 19, 2022, 8:34am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/3 "2022-12-19T08:34:06Z")
The FillCount counter is made to see if in the long term as many items are received as sent to the queue. If more items are received from the queue as sent to it the fillcount must get negativ. So that’s why the count **must** be declared signed and it may not be decremented only as long as it is greater zero. The point is not the counter gets negative. The point is that more items seem to be received then sent to the queue. In this is shown in the counter getting negative. ---
**Author:** ![hs2](https://avatars.discourse-cdn.com/v4/letter/h/a4c791/32.png) [@hs2](https://forums.freertos.org/u/hs2)\ **Post date:** [December 19, 2022, 9:07am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/4 "2022-12-19T09:07:43Z")
I’d propose to use either an atomic counter `std::atomic` if already supported by your compiler or 2 `volatile` (unsigned) counters (++send/++receive) to evaluate the difference. Inc/decrementing a normal `int` is a non-atomic operation and can produce wrong results due to race conditions. ---
**Author:** ![Shub](https://avatars.discourse-cdn.com/v4/letter/s/6f9a4e/32.png) [@Shub](https://forums.freertos.org/u/Shub)\ **Post date:** [December 19, 2022, 9:39am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/5 "2022-12-19T09:39:27Z")
I agree. It’s better to try with an atomic counter and evaluate. ---
**Author:** ![RAc](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rac/32/1389_2.png) [@RAc](https://forums.freertos.org/u/RAc)\ **Post date:** [December 19, 2022, 10:21am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/6 "2022-12-19T10:21:08Z")
I agree about the counter, a q&d solution would be a critical section in the task code (of course unneeded in the isr). The code looks ok except it looks as if your ISR may be enabled before the queue is created. If that is the case, it would typically result in a fault, though, not in the behavior you see. ---
**Author:** ![hansfrick](https://avatars.discourse-cdn.com/v4/letter/h/b2d939/32.png) [@hansfrick](https://forums.freertos.org/u/hansfrick)\ **Post date:** [December 19, 2022, 11:50am UTC](https://forums.freertos.org/t/receive-more-items-from-queue-as-sent-to-it/16416/7 "2022-12-19T11:50:54Z")
Ok, I agree to the atomic argument. I tested volatile, does not help. `std::atomic` results in a compiler error. Using portENTER\_CRITICAL() solved my problem, which seems to me to right method. Thanks everyone for help. Hans