#3835 closed enhancement (fixed)

Support statically allocated threads

Reported by: Sebastian Huber Owned by: Sebastian Huber
Priority: normal Milestone: 5.1
Component: score Version: 5
Severity: normal Keywords:
Cc: Blocked By: #3838
Blocking:

Description (last modified by Sebastian Huber)

In some applications it is desirable to have statically allocated resources for all operating system objects.

In addition to the thread control block, up to four memory areas are currently allocated by a thread:

  1. stack area
  1. TLS area
  1. FP context
  1. thread queue heads

Currently the FP context and the TLS area are separately allocated from the workspace. This complicates the workspace size estimate. Add the FP context and TLS size to the stack size and place them in the stack area. This makes it also possible to move the stack area allocation out of _Thread_Initialize(). Use a hook to get the thread queue heads which is configured depending on the unlimited objects option of the configuration.

Statically allocate the stacks for internal threads (e.g. idle and MPCI receive server) in a dedicated linker section (similar to the interrupt stacks). Mention this in the Classic API Guide configuration chapter.

Change History (35)

comment:1 Changed on Dec 9, 2019 at 11:47:18 AM by Chris Johns

Does this assume TLS is a fixed size? I would need to revisit how TLS support would be managed in the dynamic loading situation. At a guess I suspect it will break possible soluitons and that concerns me. I would prefer we do not wedged libdl in to a corner with change for a use case I do not fully understand. Maybe a detailed use case would help.

Last edited on Dec 9, 2019 at 11:49:28 AM by Chris Johns (previous) (diff)

comment:2 Changed on Dec 9, 2019 at 11:55:41 AM by Sebastian Huber

Nothing stops you from reallocating the TLS area on demand. In the worst case you waste a bit of memory. I don't think this change here will add constraints to libdl.

comment:3 Changed on Dec 9, 2019 at 11:58:24 AM by Sebastian Huber

For clarification, the pointer to the TLS area in the thread control block will remain as is.

comment:4 Changed on Dec 9, 2019 at 12:24:02 PM by Chris Johns

Great, that helps. Thanks.

comment:5 Changed on Dec 9, 2019 at 12:38:58 PM by Joel Sherrill

In at least two applications I have helped with that had custom allocators, this sounds like it might not work. They had special mmu permissions on their stack memory.

comment:6 Changed on Dec 9, 2019 at 12:51:01 PM by Sebastian Huber

I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

comment:7 Changed on Dec 11, 2019 at 2:26:21 PM by Sebastian Huber

Blocked By: 3838 added

comment:8 in reply to:  6 ; Changed on Dec 12, 2019 at 6:09:46 PM by Joel Sherrill

Replying to Sebastian Huber:

I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space).

How does this work with custom stack allocators?

comment:9 in reply to:  8 Changed on Dec 12, 2019 at 6:54:18 PM by Sebastian Huber

Replying to Joel Sherrill:

Replying to Sebastian Huber:

I would consider the FP context and the thread-local storage of a thread to be in the same access domain. These data areas should be private to a thread.

I don't know if this was intended to respond to my concern with custom stack allocators or not. In the systems I know have used this, the memory is not available (mapped dynamically) or known statically (RTEMS runs in virtual address space).

How does this work with custom stack allocators?

The availability of statically initialized threads doesn't mean that everyone has to use them. They are optional. I also have no intention to remove the custom stack allocator. What changes is that the memory area allocated for the stack is used also to contain the thread-local storage and the FP context. These memory areas are private to a thread and non-executable. I really don't know what a potential problem could be with a custom allocator.

I plan to statically initialize the stacks for the idle threads and the MPCI receive server thread. They will reside in special linker sections so that a BSP or application can control the placement in memory.

comment:10 Changed on Jan 3, 2020 at 6:37:06 AM by Sebastian Huber

Description: modified (diff)

comment:11 Changed on Feb 12, 2020 at 3:12:08 PM by Sebastian Huber <sebastian.huber@…>

In bf39a9e/rtems:

score: Remove superfluous FP types/defines

Update #3835.

comment:12 Changed on Feb 12, 2020 at 3:12:11 PM by Sebastian Huber <sebastian.huber@…>

In a0211fc9/rtems:

score: Simplify thread stack allocation

Remove superfluous Thread_Control::Start::stack member.

Update #3835.

comment:13 Changed on Feb 12, 2020 at 3:12:14 PM by Sebastian Huber <sebastian.huber@…>

In 0bde56b/rtems:

score: Simplify thread stack free

Update #3835.

comment:14 Changed on Feb 12, 2020 at 3:12:17 PM by Sebastian Huber <sebastian.huber@…>

In 0e1ac917/rtems:

score: Remove _Stack_Ensure_minimum() call

This call is superfluous since _Thread_Initialize() will do this also.

Update #3835.

comment:15 Changed on Feb 12, 2020 at 3:12:21 PM by Sebastian Huber <sebastian.huber@…>

In fc398fd/rtems:

score: Simplify FP context allocation

Use the stack area to allocate the FP context. This considerably
simplifies the application configuration since the task count no longer
influences the configured work space size. With this change the stack
space size is overestimated since an FP context for each thread is
accounted. Memory constraint applications can use the stack size for
fine tuning.

Update #3835.

comment:16 Changed on Feb 12, 2020 at 3:12:24 PM by Sebastian Huber <sebastian.huber@…>

In f4dbf37d/rtems:

score: Simplify TLS area allocation

Use the stack area to allocate the TLS area.

Update #3835.

comment:17 Changed on Feb 12, 2020 at 3:12:27 PM by Sebastian Huber <sebastian.huber@…>

In 00c7ad4/rtems:

score: Split stack allocator configuration

This allows the linker garbage collection to perform its work.

Update #3835.

comment:18 Changed on Feb 12, 2020 at 3:12:31 PM by Sebastian Huber <sebastian.huber@…>

In a08dcb2/rtems:

score: Add Thread_Configuration

Add the Thread_Configuration structure to reduce the parameter count of
_Thread_Initialize(). This makes it easier to add more parameters in
the future. It simplifies the code generation since most architectures
do not have that many registers available for function parameters.

Update #3835.

comment:19 Changed on Feb 12, 2020 at 3:12:34 PM by Sebastian Huber <sebastian.huber@…>

In 4c9deb6c/rtems:

score: Add _Stack_Extend_size()

Update #3835.

comment:20 Changed on Feb 12, 2020 at 3:12:37 PM by Sebastian Huber <sebastian.huber@…>

In 01d5944/rtems:

score: Move thread stack allocation

Move thread stack allocation to caller side of _Thread_Initialize().

Update #3835.

comment:21 Changed on Feb 12, 2020 at 3:12:40 PM by Sebastian Huber <sebastian.huber@…>

In 32991495/rtems:

score: Statically allocate idle/MPCI stacks

Place idle and MPCI stacks into extra linker sections. This can be
optionally used by applications to control the placement of the stacks.

Update #3835.

comment:22 Changed on Feb 12, 2020 at 3:12:43 PM by Sebastian Huber <sebastian.huber@…>

In 6f3bc0e/rtems:

score: Add _Objects_Free_objects_block()

This is a preparation to allow a customization of the objects
information extend.

Update #3835.

comment:23 Changed on Feb 12, 2020 at 3:12:47 PM by Sebastian Huber <sebastian.huber@…>

In 2485156/rtems:

score: Split up objects allocation

Split up the different objects allocation methods into separate
functions. This helps to avoid a dependency on the workspace in case no
objects or a static set of objects is configured.

Change license to BSD-2-Clause according to file histories.

Update #3053.
Update #3835.

comment:24 Changed on Feb 12, 2020 at 3:12:50 PM by Sebastian Huber <sebastian.huber@…>

In 6135747/rtems:

score: Split up objects free

Split up the different objects free methods into separate functions.
This helps to avoid a dependency on the workspace in case no objects or
a static set of objects is configured.

Update #3835.

comment:25 Changed on Feb 12, 2020 at 3:12:53 PM by Sebastian Huber <sebastian.huber@…>

In 8e118f22/rtems:

score: Inline _Objects_Namespace_remove_u32()

This function is simple enough to be inlined.

Update #3835.

comment:26 Changed on Feb 12, 2020 at 3:12:57 PM by Sebastian Huber <sebastian.huber@…>

In 36e59b2/rtems:

score: _Objects_Extend_information()

Return block index in _Objects_Extend_information(). This allows to
customize the objects information extend.

Update #3835.

comment:27 Changed on Feb 12, 2020 at 3:13:00 PM by Sebastian Huber <sebastian.huber@…>

In 8ff1af1/rtems:

score: Add _Freechain_Is_empty()

Update #3835.

comment:28 Changed on Feb 12, 2020 at 3:13:03 PM by Sebastian Huber <sebastian.huber@…>

In 4eab96b/rtems:

score: Add _Freechain_Pop()

Update #3835.

comment:29 Changed on Feb 12, 2020 at 3:13:06 PM by Sebastian Huber <sebastian.huber@…>

In 8a43adb/rtems:

score: Add _Freechain_Extend()

Update #3835.

comment:30 Changed on Feb 12, 2020 at 3:13:10 PM by Sebastian Huber <sebastian.huber@…>

In dd9e501/rtems:

score: Add _Objects_Activate_unlimited()

Update #3835.

comment:31 Changed on Feb 12, 2020 at 3:13:13 PM by Sebastian Huber <sebastian.huber@…>

In fc32904/rtems:

score: Add _Objects_Allocate_with_extend()

Update #3835.

comment:32 Changed on Feb 12, 2020 at 3:13:16 PM by Sebastian Huber <sebastian.huber@…>

In d252e20a/rtems:

score: Simplify _Thread_Initialize()

Allocate new thread queue heads during objects information extend. This
removes an error case and the last dependency on the workspace in
_Thread_Initialize().

Update #3835.

comment:33 Changed on Feb 25, 2020 at 8:19:35 AM by Sebastian Huber <sebastian.huber@…>

In ed15643/rtems-tools:

linkers: Update due to API changes

Update #3835.

comment:34 Changed on Feb 25, 2020 at 1:51:04 PM by Sebastian Huber <sebastian.huber@…>

In 01c97e64/rtems:

score: Fix label defined but not used warning

Update #3835.

comment:35 Changed on Mar 5, 2020 at 2:33:16 PM by Sebastian Huber <sebastian.huber@…>

Resolution: fixed
Status: assignedclosed

In c6c06ae/rtems-docs:

c-user: Document task memory

Close #3835.

Note: See TracTickets for help on using tickets.