You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
Go to file
Chris Morgan ddc89fa985 POSIX - Switch from posix timers to a timer thread to fix signal handling with non-FreeRTOS pthreads
Improve upon the elegant approach of using signals to cause task/pthreads
suspension and scheduler execution by using directed signals.

This fixes:
- Deadlocks in non-FreeRTOS pthreads
- Multiple FreeRTOS tasks(pthreads) incorrectly running at the same time

By directing the signals using pthread_kill() the signal handler in the presently running
FreeRTOS task/pthread will be called, ensuring that the scheduler runs both in the context
of a FreeRTOS task/pthread and from the presently executing FreeRTOS task/pthread.

Details
==============

The POSIX port uses signals to preempt FreeRTOS tasks (implemented as pthreads), a very neat and elegant
approach to forcing tasks/pthreads to suspend and run the scheduler.

Signal handlers are process global.

Posix timers generate signals when the timer expires, and the signal is sent to the currently
running pthread.

In systems where there are pthreads that are NOT a result of creating FreeRTOS tasks, such as the
entry point thread that calls main(), or user created pthreads, this poses a serious issue.

While the POSIX port only allows a single FreeRTOS pthread to run at once, by causing all suspended
threads to not be scheduled due to their waiting on a pthread condition variable,
this isn't the case with non-FreeRTOS pthreads.

Thus it is possible that a non-FreeRTOS pthread is running when the timer expires and the signal
is generated. This results in the signal handler running in the non-FreeRTOS thread.

The sequence of events results in these events from signal handler context:
- vPortSystemTickHandler() being called
- The scheduler running
- Selecting another FreeRTOS task to run and switching the active task
- The newly selected task released from suspension by pthread_cond_signal()
- The presently active thread calling event_wait()
- The pthread calling pthread_cond_wait(), suspending the thread and allowing the host OS scheduler
  to schedule another thread to run.

If this occurs from a non-FreeRTOS thread this results in:
- The active FreeRTOS pthread (Task A/Thread A) continuing to run (as the signal handler that calls
  event_wait() ran instead in a non-FreeRTOS pthread.
- The pthread where the signal handler did run (Thread B) will call event_wait() and pthread_cond_wait(),
  but on the condition variable of the previously active FreeRTOS task, oops. This causes the
  non-FreeRTOS pthread to block unexpectedly relative to what the developer might have expected.
- The newly selected FreeRTOS Task (Task C/Thread C) will resume and start running.

At this point Task A/Thread A is running concurrently with Task C/Thread C. While this may not
necessarily be an issue, it does not replicate the expected behavior of a single Task running at
once.

Note that Thread B will resume if/when Task A/ThreadA is switched to. However, this could be delayed
by an arbitrary amount of time, or could never occur.

Also note that if there are multiple non-FreeRTOS pthreads that Thread D, E, F...etc could suffer the
same fate as Thread B, if the scheduler were to suspend Task C/Thread C and resume Task E/Thread E.

Implementation
==============

Timer details
-------------
A standalone pthread for the signal generation thread was chosen, rather than using
a posix timer_settime() handler function because the latter creates a temporary
pthread for each handler callback. This makes debugging much more difficult due to
gdb detecting the creation and destruction of these temporary threads.

Signal delivery
--------------
While signal handlers are per-thread, it is possible for pthreads to selectively block
signals, rather than using thread directed signals. However, the approach of blocking
signals in non-FreeRTOS pthreads adds complexity to each of these non-FreeRTOS pthreads
including ensuring that these signals are blocked at thread creation, prior to the thread
starting up. Directed signals removes the requirement for non-FreeRTOS pthreads to be aware
of and take action to protect against these signals, reducing complexity.
1 year ago
.github Add new common words to the cSpellWordList.txt (#946) 1 year ago
examples Rename sample configuration to template configuration (#927) 1 year ago
include Added ability to change task notification index for streambuffers (#939) 1 year ago
portable POSIX - Switch from posix timers to a timer thread to fix signal handling with non-FreeRTOS pthreads 1 year ago
.git-blame-ignore-revs Introduce .git-blame-ignore-revs 2 years ago
.gitattributes Enable automatic EOL conversion by git 2 years ago
.gitmodules Move the community/partner supported ports to correct location (#361) 4 years ago
CMakeLists.txt aarch64: Rename ARM_CA53_64_BIT/_SRE to Arm_AARCH64/_SRE (#822) 1 year ago
GitHub-FreeRTOS-Kernel-Home.url Normalize line endings and whitespace in source files 2 years ago
History.txt Update History.txt for V11.0.1 (#932) 1 year ago
LICENSE.md Bring license in sync with FreeRTOS/FreeRTOS. (#20) 5 years ago
MISRA.md Add coverity example (#870) 1 year ago
Quick_Start_Guide.url Normalize line endings and whitespace in source files 2 years ago
README.md Rename sample configuration to template configuration (#927) 1 year ago
croutine.c Suppress MISRA C:2012 rule 11.5 deviations (#878) 1 year ago
cspell.config.yaml CI-CD Updates (#768) 2 years ago
event_groups.c Remove lint suppression comment (#920) 1 year ago
list.c Remove lint suppression comment (#920) 1 year ago
manifest.yml Version Change (#587) 2 years ago
queue.c Remove lint suppression comment (#920) 1 year ago
stream_buffer.c Added ability to change task notification index for streambuffers (#939) 1 year ago
tasks.c Assign idle task to each core before SMP scheduler start (#945) 1 year ago
timers.c Remove lint suppression comment (#920) 1 year ago

README.md

CMock Unit Tests codecov

Getting started

This repository contains FreeRTOS kernel source/header files and kernel ports only. This repository is referenced as a submodule in FreeRTOS/FreeRTOS repository, which contains pre-configured demo application projects under FreeRTOS/Demo directory.

The easiest way to use FreeRTOS is to start with one of the pre-configured demo application projects. That way you will have the correct FreeRTOS source files included, and the correct include paths configured. Once a demo application is building and executing you can remove the demo application files, and start to add in your own application source files. See the FreeRTOS Kernel Quick Start Guide for detailed instructions and other useful links.

Additionally, for FreeRTOS kernel feature information refer to the Developer Documentation, and API Reference.

Also for contributing and creating a Pull Request please refer to the instructions here.

Getting help

If you have any questions or need assistance troubleshooting your FreeRTOS project, we have an active community that can help on the FreeRTOS Community Support Forum.

To consume FreeRTOS-Kernel

Consume with CMake

If using CMake, it is recommended to use this repository using FetchContent. Add the following into your project's main or a subdirectory's CMakeLists.txt:

  • Define the source and version/tag you want to use:
FetchContent_Declare( freertos_kernel
  GIT_REPOSITORY https://github.com/FreeRTOS/FreeRTOS-Kernel.git
  GIT_TAG        main #Note: Best practice to use specific git-hash or tagged version
)

In case you prefer to add it as a git submodule, do:

git submodule add https://github.com/FreeRTOS/FreeRTOS-Kernel.git <path of the submodule>
git submodule update --init
  • Add a freertos_config library (typically an INTERFACE library) The following assumes the directory structure:
    • include/FreeRTOSConfig.h
add_library(freertos_config INTERFACE)

target_include_directories(freertos_config SYSTEM
INTERFACE
    include
)

target_compile_definitions(freertos_config
  INTERFACE
    projCOVERAGE_TEST=0
)

In case you installed FreeRTOS-Kernel as a submodule, you will have to add it as a subdirectory:

add_subdirectory(${FREERTOS_PATH})
  • Configure the FreeRTOS-Kernel and make it available
    • this particular example supports a native and cross-compiled build option.
set( FREERTOS_HEAP "4" CACHE STRING "" FORCE)
# Select the native compile PORT
set( FREERTOS_PORT "GCC_POSIX" CACHE STRING "" FORCE)
# Select the cross-compile PORT
if (CMAKE_CROSSCOMPILING)
  set(FREERTOS_PORT "GCC_ARM_CA9" CACHE STRING "" FORCE)
endif()

FetchContent_MakeAvailable(freertos_kernel)
  • In case of cross compilation, you should also add the following to freertos_config:
target_compile_definitions(freertos_config INTERFACE ${definitions})
target_compile_options(freertos_config INTERFACE ${options})

Consuming stand-alone - Cloning this repository

To clone using HTTPS:

git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git

Using SSH:

git clone git@github.com:FreeRTOS/FreeRTOS-Kernel.git

Repository structure

  • The root of this repository contains the three files that are common to every port - list.c, queue.c and tasks.c. The kernel is contained within these three files. croutine.c implements the optional co-routine functionality - which is normally only used on very memory limited systems.

  • The ./portable directory contains the files that are specific to a particular microcontroller and/or compiler. See the readme file in the ./portable directory for more information.

  • The ./include directory contains the real time kernel header files.

  • The ./template_configuration directory contains a sample FreeRTOSConfig.h to help jumpstart a new project. See the FreeRTOSConfig.h file for instructions.

Code Formatting

FreeRTOS files are formatted using the "uncrustify" tool. The configuration file used by uncrustify can be found in the FreeRTOS/CI-CD-GitHub-Actions's uncrustify.cfg file.

Line Endings

File checked into the FreeRTOS-Kernel repository use unix-style LF line endings for the best compatibility with git.

For optimal compatibility with Microsoft Windows tools, it is best to enable the git autocrlf feature. You can enable this setting for the current repository using the following command:

git config core.autocrlf true

Git History Optimizations

Some commits in this repository perform large refactors which touch many lines and lead to unwanted behavior when using the git blame command. You can configure git to ignore the list of large refactor commits in this repository with the following command:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Spelling and Formatting

We recommend using Visual Studio Code, commonly referred to as VSCode, when working on the FreeRTOS-Kernel. The FreeRTOS-Kernel also uses cSpell as part of its spelling check. The config file for which can be found at cspell.config.yaml There is additionally a cSpell plugin for VSCode that can be used as well. .cSpellWords.txt contains words that are not traditionally found in an English dictionary. It is used by the spellchecker to verify the various jargon, variable names, and other odd words used in the FreeRTOS code base are correct. If your pull request fails to pass the spelling and you believe this is a mistake, then add the word to .cSpellWords.txt. When adding a word please then sort the list, which can be done by running the bash command: sort -u .cSpellWords.txt -o .cSpellWords.txt Note that only the FreeRTOS-Kernel Source Files, include, portable/MemMang, and portable/Common files are checked for proper spelling, and formatting at this time.