Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Concurrency Question

Posted by tblackmon on March 28, 2014

I am evaluating the use of FreeRTOS in an application. As part of this, I have been reading the source code. There is a location where I am confused on how concurrency issues are prevented on the xNextTaskUnblockTime variable.

My concerning case is the following. I know it's complicated, but I hope it shows the point.

4 Tasks from highest to lowest priority:

A Highest priority, but blocked waiting on I/O B Waiting to wake in 100 ticks C Running D Sleeping, lowest priority

C calls vTaskSuspend to suspend D (task.c:1191) STARTCRITICAL pxTCB is task to suspend removes from ready/delayed list removes from event list add to suspended list ENDCRITICAL call prvResetNextTaskUnblockTime (task.c:1262 calling task.c:3090) delayed list is not empty get the owner of head entry calc the xNextTaskUnblockTime for 100 ticks later, but not yet stored.

The IO interrupt unblocks task A

A runs, does stuff. A calls vTaskSuspend for itself for 1 ticks. This updates the xNextTaskUnblockTime for 5 ticks later.

C runs again, finishing the assignment of setting xNextTaskUnblockTime for 100 ticks later. I think this is an error.

...time passes...

xTaskIncrementTick is called. (task.c:1841) NOTE: uxScheduler suspended is false. ++xTickCount NOTE: No switch is required. xConstTickCount is NOT greater/equal than the tick count (even though it should be.)

Is there something I'm missing.

Concurrency Question

Posted by rtel on March 28, 2014

On first inspection I agree, this does look like an error, and if it turns out to be so the same error is probably in the vTaskDelete() function. Again, only from a first preliminary inspection, the other uses of xNextTaskUnblockTime look ok.

This will get investigated fully. Expect to be able to report back within 10 days (hopefully sooner). In the mean time putting a critical section around the call to prvResetNextTaskUnblockTime() will not do any harm, but definitely do not put the critical section inside the call to prvResetNextTaskUnblockTime() as that definitely will do some harm (on some ports anyway).

Thanks for your input.


Concurrency Question

Posted by rtel on March 31, 2014

See lines 765 and 1268 on the following link (or at least revision 2233 of the file). Please let me know if you see any issues.



Concurrency Question

Posted by tblackmon on March 31, 2014

I read through it again, and I don't see any other issues on that variable.

All reads are atomic, and It looks like the variable is written only when: 1. In non-interrupts where the scheduler is suspended, or 2. In non-interrupts where interrupts are disabled, or 3. In interrupts where it has determined that the scheduler is suspended.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.


FreeRTOS and other embedded software careers at AWS.

Latest News

FreeRTOS kernel V10.0.1 is available for immediate download. Now MIT licensed.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner