[RTOS Support] FreeRTOS kernel code problem

The FreeRTOS kernel is now an MIT licensed AWS open source project, and these pages are being updated accordingly.

Quality RTOS & Embedded Software

About Contact Support FAQ Download

Menu

Quick Start

Supported MCUs

PDF Books

Trace Tools

Ecosystem

Quick Start Guide

Support Forum

⇓ Download Source ⇓

FreeRTOS+ Ecosystem

FreeRTOS+TCP:
Thread safe TCP/IP stack

SafeRTOS:
TUV certified RTOS

OpenRTOS:
Commercial Licensed RTOS

Fail Safe File System:
Ensures data integrity

FreeRTOS BSPs:
3rd party driver packages

Trace & Visualisation:
Tracealyzer for FreeRTOS

CLI:
Command line interface

WolfSSL SSL / TLS:
Networking security protocols

RTOS Training:
Delivered online or on-site

IO:
read(), write(), ioctl() interface

FreeRTOS+ Lab Projects

FreeRTOS+POSIX:
POSIX threading API

FreeRTOS+FAT:
Thread aware file system

FreeRTOS Support Archive

The FreeRTOS support forum is used to obtain active support directly from Real Time Engineers Ltd. In return for using our top quality software and services for free, we request you play fair and do your bit to help others too! Sign up to receive notifications of new support topics then help where you can.

This is a read only archive of threads posted to the FreeRTOS support forum. The archive is updated every week, so will not always contain the very latest posts. Use these archive pages to search previous posts. Use the Live FreeRTOS Forum link to reply to a post, or start a new support thread.

[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [November 2013 Threads]

FreeRTOS kernel code problem

Posted by zhudinum1 on November 18, 2013

why use variable xPendingReadyList in the source code ? it can insert ready task into readylist directly without causing any safe problems. very appreciate for your answering in time!

FreeRTOS kernel code problem

Posted by richardbarry on November 18, 2013

xPendingReadyList is used to temporarily hold tasks that have been moved into the Ready state by an interrupt while the scheduler was locked. Its use allows interrupts to remain enabled when the scheduler is locked. Scheduler locking is a lighter form of critical section that prevents the kernel from performing context switches. The alternative is to use a full critical section, but that would mean at least a subset of interrupt priorities would be masked.

Regards.

FreeRTOS kernel code problem

Posted by zhudinum1 on November 19, 2013

Ok thank you! But why we can not insert the tasks that have been moved into the Ready into the pxReadyTasksLists directly while the scheduler was locked? In the security considerations ?

Regards

FreeRTOS kernel code problem

Posted by richard_damon on November 19, 2013

Locking the scheduler is one way to implement a critical section when internal state is being manipulated. If the task that locked the schedule is doing something to the ready list, the LAST thing you want to do is manipulate it yourself, the like result is a corrupted list.