workspace structure

[Joel Sherrill]

Catalin Morosan wrote:
> The workspace structure from my last mail was after looking at the rtems
> 4.6.6 source code. So I guess rtems 4.6.6 allocates memory from the end
> of a free block...
>   
Yes 4.7 was the transition to allocating from the beginning.

malloc() followed by an immediate realloc() will always fail
to extend the malloc'ed block of memory in 4.6 and be
forced to malloc a second block and copy it.

This change made it possible for realloc() to actually
extend a block more frequently.
> Joel Sherrill wrote:
>   
>> Catalin Morosan wrote:
>>     
>>> Hi.
>>>
>>> I've been trying to understand what exactly is the structure of the
>>> workspace in memory, especially where are the information for the
>>> threads and where are the stacks kept. I understand that the workspace
>>> is allocated at the end of the memory and is like a separate heap.
>>>
>>> After doing some debugging of an application with 4 tasks I deduced
>>> this:
>>>
>>> ---beginning of workspace
>>> ...
>>> Task 4 stack
>>> Task 3 stack
>>> Task 2 stack
>>> Task 1 stack
>>> Task idle stack
>>> ..
>>> Task 1 control block
>>> Task 2 control block
>>> Task 3 control block
>>> Task 4 control block
>>> Task idle control block
>>> ..
>>> --- end of workspace
>>>
>>> Is this accurate?
>>>
>>>       
>> I don't think it is 100% accurate even ignoring the ...'s
>>
>> First in older RTEMS versions, the heap allocated memory
>> from the end of a free block -- now it does it from the beginning
>> of a free block so there is a chance of realloc() working.
>>
>> Each class of control block is allocated as a contiguous
>> array.  So your task 1..4 CB's are contiguous.
>>
>> Internal tasks such as IDLE are allocated first so (in current
>> RTEMS), the IDLE TCB address will be lower than the first
>> Classic API task.  See this I printed by breaking at Init
>>
>> (gdb) p _Thread_Executing
>> $1 = (Thread_Control *) 0x7dc2e8
>> (gdb) p _Thread_Idle
>> $2 = (Thread_Control *) 0x7dc148
>>
>> Notice IDLE is lower than Init (Classic API task 1)
>>
>> The stacks are not allocated until the task is created which
>> (except for IDLE) is potentially long after RTEMS is initialized.
>> Again in gdb at the same point.
>> (gdb) p _Thread_Executing->Start.Initial_stack.area
>> $4 = (void *) 0x7df2c0
>> (gdb) p _Thread_Idle->Start.Initial_stack.area
>> $5 = (void *) 0x7dcd48
>>
>> IDLE's stack was allocated before  the Classic API init task.
>>
>> The layout of Workspace memory is strictly a function of the
>> order of initialization inside RTEMS and the order in which
>> your application creates object such as tasks (stacks) and
>> message queues (buffers).
>>
>> In summary, the only thing vaguely guaranteed is that the
>> control blocks for objects within a single class were
>> allocated as an array.
>>     
>>> Also, I don't understand why it has this structure because
>>> _Workspace_Allocate() takes only the size of memory to be allocated and
>>> in turn, it calls _Heap_Allocate() with the size and the information for
>>> the workspace. Doesn't allocation start from the beginning of the
>>> workspace and continues to the end? Why is the task idle control block
>>> after the control blocks of the other tasks although the idle task is
>>> created first? etc. There is something I am missing but I can't see it
>>> right now.
>>>
>>>
>>>       
>> All control blocks are allocated then the stacks are
>> allocated as the TCBs are used.
>>
>> For all non-system tasks, the TCB is allocated during init and
>> the stack is allocated at create time so they are not even
>> close to contiguous in memory.
>>     
>>> Thanks for any input.
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>       
>>     


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985