----- Am 17. Nov 2018 um 2:02 schrieb Chris Johns chr...@rtems.org:
> On 16/11/18 5:08 pm, Sebastian Huber wrote:
>> The RTEMS_USE_16_BIT_OBJECT define is not set by an RTEMS port. Remove
>> support for 16-bit object identifiers. If someone really wants to use
>> RTEMS on a 16-bit target, then it is better to use self-contained
>> objects instead of playing around with object identifier optimizations.
>
> Are self-contained threads supported?
Self-contained threads are not yet supported. There are some steps left to
realize them.
One issue is that the existing APIs using a thread ID should also work with
threads without a normal object ID. We could remove one bit from the object
class field and use it to indicate if the ID is a normal object ID or a pointer
(the pointer address must be at least 2-byte aligned). In case the normal
lookup fails, then we check the bit and if it set, then we assume it is a
pointer to a TCB.
Another problem is that the TCB has a configuration defined size. We could
layout self-contained threads like this:
TCP
space for configuration defined TCB content
space for thread-local storage (size defined at link-time)
space for POSIX key value pairs
space for stack
#define RTEMS_THREAD_DEFINE(name, size)
struct {
Thread_Control TCB;
char space[size];
} _Thread_Object_##name;
static const Thread_Configuration _Thread_Config_##name = {
.name = #name,
.object = &_Thread_Object_##name.TCB,
.size = size
};
RTEMS_ROSET_ITEM(_Threads, &_Thread_Config_##name)
The threads need a static constructor, if the allocated size is too small, then
we issue a fatal error.
I think we should move the POSIX key value pairs to thread-specific storage
(for example at the end of the stack area, a stack overflow would then first
hit the POSIX key values of the same thread) for SMP performance reasons and
memory management issues with the free list which is currently used.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
