Quality RTOS & Embedded Software

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


Big Concurrency Problem, Help needed!

Posted by Christian Koerber on July 21, 2006

My team and I are currently completely redesigning our serially executed system in order to use FreeRTOS, which introduced a lot of concurrency and successivly unforseen related problems.

To give one (the biggest problem) example:
We plan to use a Cache-Manager-Task, which manages all concurrent accesses to flash memory.

Writing to Cache is no problem, since we send message containg a pointer to dynamic memory. Ownership to this memory will be granted to the Cache, which will free the dynamic memory once it is copied to flash. Thus, any task writing to cache (by sending a message to the Chache's queue, can continue to execute it's code.

Reading from cache is a BIG problem, though:
The task wishing to read sends an appropriate message to the task, together with a pointer into which the Cashe should read the flash into.
Unfortunately, the task must now wait, until the Cache sends a message, that the read as been performed. This introduces a lot of problems:

1. Our code becomes fragmented, if several reads must be performed, mostly because, Reads are limited to flash pages (256 byte). We can no longer loop over the flash.

2. Since we must wait for the cache, other events (messages) may have been put into our task's queue, before the result message from the cache arrives, introducing very nasty concurrency.

I have no idea about what to do aside from writing very complex code, which frustrates me and my team a lot.

Is there any possibility to halt my task and somehow continue at the exact place from where the read request was sended, thus bypassing the message queue?

best regards,


RE: Big Concurrency Problem, Help needed!

Posted by Nobody/Anonymous on July 21, 2006
How did your old system do this? Did it just wait for all flash access to complete?

I would guess that you write to flash much less frequently than you read from it. Is it possible for two tasks to read the flash at the same time, with just writing to it the part that must be guarded. Maybe you could change your cache task to only handle writes and set a lock bit when the flash is currently being written. The tasks that read need then only get the lock and read directly.

Maybe this is too simplistic.

Where is the flash? Built into the chip or on a bus? Serial bus or parallel bus if relevant.

RE: Big Concurrency Problem, Help needed!

Posted by Nobody/Anonymous on July 21, 2006
I suggest you use a second queue for only the returns of a read action from the flash manager. Then block on this queue after a read request. The return could also give you information like read success or fail.

[ 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.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

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