Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

#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: qualification
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 (41)

comment:1 Changed on 12/09/19 at 11:47:18 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 12/09/19 at 11:49:28 by Chris Johns (previous) (diff)

comment:2 Changed on 12/09/19 at 11:55:41 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 12/09/19 at 11:58:24 by Sebastian Huber

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

comment:4 Changed on 12/09/19 at 12:24:02 by Chris Johns

Great, that helps. Thanks.

comment:5 Changed on 12/09/19 at 12:38:58 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 12/09/19 at 12:51:01 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 12/11/19 at 14:26:21 by Sebastian Huber

Blocked By: 3838 added

comment:8 in reply to:  6 ; Changed on 12/12/19 at 18:09:46 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 12/12/19 at 18:54:18 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 01/03/20 at 06:37:06 by Sebastian Huber

Description: modified (diff)

comment:11 Changed on 02/12/20 at 15:12:08 by Sebastian Huber <sebastian.huber@…>

In [changeset:"bf39a9e2a8f94f44a0bb0415e8a15a1a51418568/rtems" bf39a9e/rtems]:

score: Remove superfluous FP types/defines

Update #3835.

comment:12 Changed on 02/12/20 at 15:12:11 by Sebastian Huber <sebastian.huber@…>

In [changeset:"a0211fc9f9883d0a1182548de11ab0e0505a81c6/rtems" a0211fc9/rtems]:

score: Simplify thread stack allocation

Remove superfluous Thread_Control::Start::stack member.

Update #3835.

comment:13 Changed on 02/12/20 at 15:12:14 by Sebastian Huber <sebastian.huber@…>

In [changeset:"0bde56b1b4ef7468188712c86e6bd2793532ddc9/rtems" 0bde56b/rtems]:

score: Simplify thread stack free

Update #3835.

comment:14 Changed on 02/12/20 at 15:12:17 by Sebastian Huber <sebastian.huber@…>

In [changeset:"0e1ac9171a4342daecdf99378f7c7bb8bdd8a227/rtems" 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 02/12/20 at 15:12:21 by Sebastian Huber <sebastian.huber@…>

In [changeset:"fc398fde77d25c086e109403eddd6de267982653/rtems" 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 02/12/20 at 15:12:24 by Sebastian Huber <sebastian.huber@…>

In [changeset:"f4dbf37dd432623c345f8e19f78a4eb01fcedb8b/rtems" f4dbf37d/rtems]:

score: Simplify TLS area allocation

Use the stack area to allocate the TLS area.

Update #3835.

comment:17 Changed on 02/12/20 at 15:12:27 by Sebastian Huber <sebastian.huber@…>

In [changeset:"00c7ad4cab30aba80639ace29526c1efc2779074/rtems" 00c7ad4/rtems]:

score: Split stack allocator configuration

This allows the linker garbage collection to perform its work.

Update #3835.

comment:18 Changed on 02/12/20 at 15:12:31 by Sebastian Huber <sebastian.huber@…>

In [changeset:"a08dcb2f7c7c883559e10c389404a4dc751376fa/rtems" 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 02/12/20 at 15:12:34 by Sebastian Huber <sebastian.huber@…>

In [changeset:"4c9deb6c10ad2ccab37da5723748841dbc73f0d2/rtems" 4c9deb6c/rtems]:

score: Add _Stack_Extend_size()

Update #3835.

comment:20 Changed on 02/12/20 at 15:12:37 by Sebastian Huber <sebastian.huber@…>

In [changeset:"01d59443b06ab351039cbc63a688cfa87f196ea0/rtems" 01d5944/rtems]:

score: Move thread stack allocation

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

Update #3835.

comment:21 Changed on 02/12/20 at 15:12:40 by Sebastian Huber <sebastian.huber@…>

In [changeset:"32991495b48d1b5e4804b2f10a67a800f4608e75/rtems" 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 02/12/20 at 15:12:43 by Sebastian Huber <sebastian.huber@…>

In [changeset:"6f3bc0e3201c903773719c369081bca06f891f1a/rtems" 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 02/12/20 at 15:12:47 by Sebastian Huber <sebastian.huber@…>

In [changeset:"24851567c38f573e9176529e9ca431fbf80c6cef/rtems" 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 02/12/20 at 15:12:50 by Sebastian Huber <sebastian.huber@…>

In [changeset:"61357479894b08c9017ba39f90572c57dc307869/rtems" 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 02/12/20 at 15:12:53 by Sebastian Huber <sebastian.huber@…>

In [changeset:"8e118f2275bf1093b0ed3c66a7bd7535fd61b29e/rtems" 8e118f22/rtems]:

score: Inline _Objects_Namespace_remove_u32()

This function is simple enough to be inlined.

Update #3835.

comment:26 Changed on 02/12/20 at 15:12:57 by Sebastian Huber <sebastian.huber@…>

In [changeset:"36e59b2bbc8737c4ba1b93ac0f695528a36844c9/rtems" 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 02/12/20 at 15:13:00 by Sebastian Huber <sebastian.huber@…>

In [changeset:"8ff1af16551eedd7e98af6c65a91bb62b9403991/rtems" 8ff1af1/rtems]:

score: Add _Freechain_Is_empty()

Update #3835.

comment:28 Changed on 02/12/20 at 15:13:03 by Sebastian Huber <sebastian.huber@…>

In [changeset:"4eab96bbb421018c17f984c1c3a4220abe16c788/rtems" 4eab96b/rtems]:

score: Add _Freechain_Pop()

Update #3835.

comment:29 Changed on 02/12/20 at 15:13:06 by Sebastian Huber <sebastian.huber@…>

In [changeset:"8a43adbe47454689149bac27adc45439eab44965/rtems" 8a43adb/rtems]:

score: Add _Freechain_Extend()

Update #3835.

comment:30 Changed on 02/12/20 at 15:13:10 by Sebastian Huber <sebastian.huber@…>

In [changeset:"dd9e50102b6829c018b6ea24e925cf26e924273f/rtems" dd9e501/rtems]:

score: Add _Objects_Activate_unlimited()

Update #3835.

comment:31 Changed on 02/12/20 at 15:13:13 by Sebastian Huber <sebastian.huber@…>

In [changeset:"fc32904f4a270976961d61385be44c56fcc6fd01/rtems" fc32904/rtems]:

score: Add _Objects_Allocate_with_extend()

Update #3835.

comment:32 Changed on 02/12/20 at 15:13:16 by Sebastian Huber <sebastian.huber@…>

In [changeset:"d252e20ab5717afea2ac89543ab4e0d379434bb0/rtems" 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 02/25/20 at 08:19:35 by Sebastian Huber <sebastian.huber@…>

In [changeset:"ed15643221ca252e8a82a5d771487a51d8bb094b/rtems-tools" ed15643/rtems-tools]:

linkers: Update due to API changes

Update #3835.

comment:34 Changed on 02/25/20 at 13:51:04 by Sebastian Huber <sebastian.huber@…>

In [changeset:"01c97e643a83c80093e0390a5ebc3465dec60426/rtems" 01c97e64/rtems]:

score: Fix label defined but not used warning

Update #3835.

comment:35 Changed on 03/05/20 at 14:33:16 by Sebastian Huber <sebastian.huber@…>

Resolution: fixed
Status: assignedclosed

In [changeset:"c6c06aecbb78b1b6baedb2a0863fc244e96a671d/rtems-docs" c6c06ae/rtems-docs]:

c-user: Document task memory

Close #3835.

comment:36 Changed on 06/23/21 at 07:16:03 by Sebastian Huber

Keywords: qualification added

comment:37 Changed on 10/14/22 at 09:41:47 by Sebastian Huber <sebastian.huber@…>

In [changeset:"15bba4aecfca407d67e495b7a26c84929202d05f/rtems" 15bba4ae/rtems]:

score: Move Thread_Control::Registers member

Place this member placed directly after the end of the common block so that
the structure offsets are as small as possible. This helps on instruction
set architectures with a very limited range for intermediate values. For
example, see the aeabi_read_tp() implementation for ARM Thumb-1.

Update #3835.

comment:38 Changed on 10/14/22 at 09:41:49 by Sebastian Huber <sebastian.huber@…>

In [changeset:"4c89fbcd316ca99fa16a0acc31f88fb80cb3060f/rtems" 4c89fbcd/rtems]:

score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

Update #3835.

comment:39 Changed on 10/14/22 at 09:42:01 by Sebastian Huber <sebastian.huber@…>

In [changeset:"45ee958552ca35b6834985718ecd59b27fc52f86/rtems" 45ee958/rtems]:

config: Add CONFIGURE_IDLE_TASK_STORAGE_SIZE

By default, allocate the IDLE task storage areas from the RTEMS Workspace.
This avoids having to estimate the thread-local storage size in the default
configuration.

Add the application configuration option CONFIGURE_IDLE_TASK_STORAGE_SIZE to
request a static allocation of the task storage area for IDLE tasks.

Update #3835.
Update #4524.

comment:40 Changed on 10/14/22 at 09:42:03 by Sebastian Huber <sebastian.huber@…>

In [changeset:"64fbeaa0d1b4321cb439923c86993d134fbd3acb/rtems" 64fbeaa/rtems]:

score: INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL

Ensure that the IDLE storage allocator did allocate a suffiently large area.

Update #3835.
Update #4524.

comment:41 Changed on 11/10/22 at 09:58:49 by Sebastian Huber <sebastian.huber@…>

In [changeset:"8f6dd3ca1fa9c7772746fcd2f487e504e6968598/rtems" 8f6dd3c/rtems]:

arm: Fix Armv7-M TLS support

Set the thread ID register in the CPU context.

Update #3835.
Close #4753.

Note: See TracTickets for help on using tickets.