On 04/11/2020 19:38, Gedare Bloom wrote:
Based on the above suggestions I tried to move the User_extensions_Iterator
storage to the TCB by adding a new field to the structure, but that did not
compile(userextimpl.h is not included with thread.h because of cyclic
dependency).
This made me try out a naive hack, I defined a structure similar to the
User_extensions_Iterator and then added the field to the TCB. The next problem
that I faced was during the creation of the idle thread. Since an idle thread
is created during system
initialization, the 'executing' pointer pointing the TCB is null, and hence
referencing to the iterator placed in the TCB for the idle thread fails. This
was resolved by separating the cases for an idle thread and other threads.
After that I was able to successfully isolate more than two thread stacks.
Can you please suggest a more acceptable approach for resolving this issue?
At a high level the approach you took makes sense. You have moved the
user extensions to the TCB, and then avoid accessing it in case the
TCB is null (i.e., the initial context switch). I'd need to see the
code to make any further critical analysis. But it sounds acceptable
to me.
The executing thread pointer can be NULL and there is already a check
for this in _User_extensions_Iterate(). In this case you can use a
member in the _Per_CPU_Information[].
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
