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] [July 2006 Threads] 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|