On September 10, 2015 2:37:35 AM CDT, Peter Dufault <dufa...@hda.com> wrote: > >> On Sep 9, 2015, at 19:02 , Joel Sherrill <joel.sherr...@oarcorp.com> >wrote: >> >> As Sebastian mentioned if you make the task stack accessible by only >> a single stack, you have to be careful not to pass pointers to >objects >> on the stack into paths where they will be used by another task. > >I’ve worked on multi-processor systems with this attribute and I think >it’s a good option, stack was private and “cheap” in terms of overhead >on a processor. If you use shared memory semantics you'll have >portable code that works on multi-process (process, not processor) >systems, it requires a little more design formalism up front.
I don't think this is a huge issue to avoid in application code. The only common case I can think of is RTEMS calls writing status and messages back into stack variables as part of unblocking a task. My main point was that it would be good to take a holistic view and try to do the best for each type of memory object. Otherwise we end up potentially missing an opportunity or with an odd design limit because we focused on a specific implementation and application. >Peter >----------------- >Peter Dufault >HD Associates, Inc. Software and System Engineering --joel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
