AVR32 UC3 port: vTaskDelay thread- and interrupt-safe?

Kernel
1

threis wrote on Wednesday, April 30, 2014:

Hi,

when i look at the function vTaskDelay() i wondered about the missing entering of a critical section at the beginning of the function. The function call of vTaskSuspendAll() just increment the variable uxSchedulerSuspended, which e.g. is polled at context switch. If an timer interrupt occurs during vTaskDelay() is processed, this function would interrupted before the calling task could inserted into the list of delayed tasks. If then the timer interrupt would processed and check if there are tasks ready to run, these tasks would removed from the delayed task list and put in the ready task list.
If now the cpu returned to processing of the function where the interrupt occured, this list of delayed tasks would corrupted. I think the call of vTaskDelay() must be thread- and interrupt-safe. What do you thing about? Do you agree with my conclusion or is there anything i didn’t consider?

I’m using the AVR32 UC3 port.

Please excuse my english.
Thank you

2

rtel wrote on Wednesday, April 30, 2014:

FreeRTOS minimises its use of critical sections in order to remain as responsive to interrupts as possible. It uses the scheduler locking as a means of allowing interrupts to remain enabled. When the scheduler is locked the kernel’s data structures are protected from interference from the timer (or any other interrupt that is written correctly). Instead such interrupts manipulate a set of ‘pending’ data structures. Any ‘pending’ updates are processed into the main kernel data structures when the scheduler is unlocked.

Note the UC3 port in the main FreeRTOS download is no longer supported as it only runs on ES chips (it works around silicon bugs that no longer exist in the chips). Atmel have their own port in the ASF, but we are understandably unable to support third party code directly.

Regards.