Quality RTOS & Embedded Software

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


vTaskDelay and task starvation

Posted by nndpkz on June 5, 2018


I have rather simple question which is probably due to my misunderstanding of basic RTOS scheduling. If 2 tasks like this:

~~~ void task1() { while(1) { xilprintf("1"); vTaskDelay( pdMSTO_TICKS( 1000UL ) ); } }

void task2() { while(1) { xil_printf("2"); } } ~~~

are run with same priorites, I've noticed that task1 will never be executed due to delay. Once I remove delay, the processing time between tasks is divided as expected.

Can anyone explain me this?

Best regards, Nenad

vTaskDelay and task starvation

Posted by dcrocker on June 5, 2018

Richard will probably provide a detailed explanation of what is going on. However, it looks to me that you are relying solely on the tick interrupt to share CPU time between the two tasks. This is rarely a good idea. If the printf function includes a mutex to prevent the output getting garbled, then most times the tick interrupt occurs, task2 will own that mutex so task1 can't be scheduled.

I would try one or both of the following to resolve the problem:

  1. Increase the priority of task 1. It spends most of its time delaying, so you can do this without starving task 2 of CPU time.
  2. Add a taskYIELD call at the bottom of the task2 loop, so that you are not relying solely on the tick interrupt to schedule CPU time between it and other tasks of equal priority.

vTaskDelay and task starvation

Posted by rtel on June 5, 2018

As per David's reply - a lot will depend on how the xilprintf() is implemented. Is it thread safe? If so, how is it made thread safe (see David's reply). If it's not thread safe, then what you are doing is dangerous as any state inside xilprintf() (like its access to whichever console you are writing to) could get corrupted - even if no data gets corrupted you could get strings interleaved at the output as you are printing from two tasks simultaneously. Does xil_printf() block (not return until all data has been output)? If so, then your application will be running extremely slowly. Etc. A good proportion of support requests that have a call to printf() in them are caused by the printf() call itself. You can serialise print output by having a logging task - when a task wants to print something it writes the message it wants to print to a queue and the logging task reads the data from the queue and writes it to the output port at a very low task priority.

vTaskDelay and task starvation

Posted by nndpkz on June 6, 2018

Hi guys,

thank you for your help. It seems indeed that this was the problem with xilprintf() after all. I made another quick test such as: ~~~ void task1() { while(1) { xilprintf("1"); vTaskDelay( pdMSTOTICKS( 1000UL ) ); } }

void task2() { int i = 0; while(1) { i++; } } ~~~

and both tasks were executing expected (I checked task2 in debug mode). Also, if there isn't any call to xil_printf in task1 neither, than it also executes as expected.

Best regards, Nenad

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

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

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo & Nuvoton Cortex-M23 demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

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