Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Big Concurrency Problem, Help needed!

Posted by Christian Koerber on July 21, 2006
Hello,

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,

Christian





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 ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists