> On Mar 8, 2020, at 15:28 , dufa...@hda.com wrote:
>
> I have not gone through this thread as thoroughly as I should. Yet, I will
> still jump in.
>
> The stack protectin mechanism should be done in a POSIX compliant way without
> defining any extensions.
>
> When threads have protected stack areas that must be shared those regions
> should be shared using an "mmap" interface. That is POSIX compliant, and will
> require extra effort to establish the sharing of stack-based memory regions.
>
> My two minute analysis of "thread pools" is that protected stacks in RTEMS
> should be implemented without that. Applications that want protected stacks
> should have the discipline of explicitly requesting access to regions of
> memory that are in another threads stack. The value of protected stacks will
> not be cost free.
>
> I'd like to see:
>
> - The ability of each thread to specify a protected stack.
> - A protected thread's stack memory region shall be unavailable to other
> threads unless it is in a shared memory region.
> -- I won't define the granularity of what the previous point means. In most
> implementations, it probably means that if "task2" has access to memory in
> the "task1" stack via mmap then it can probably stomp all over any part of
> task1s stack, it probably implies that the task1 stack memory is left
> accessible when task2 is running instead of being unmapped.
In the Olden Days I worked on an architecture (Alliant mini supercomputers)
where the stack wasn't in shared memory. It took a little bit of getting used
to, but not much. In that architecture you just couldn't share the stack, no
hope to "mmap" anything.
We should define the goal of protected stacks. My goal is increased robustness
at the expense of additional application setup complexity, but the application
setup should be 100% POSIX compliant.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
