From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
Newsgroups: | comp.compilers |
Date: | Sun, 18 Jan 2015 21:47:49 +0000 (UTC) |
Organization: | Aioe.org NNTP Server |
References: | 15-01-015 15-01-027 |
Keywords: | parallel, architecture, comment |
Posted-Date: | 18 Jan 2015 17:06:12 EST |
George Neuner <gneuner2@comcast.net> wrote:
> On Thu, 15 Jan 2015 23:54:57 -0800, Ivan Godard <ivan@ootbcomp.com>
> wrote:
>>If a process has two or more threads running in it, what are the rules
>>regarding one thread referencing memory in a different thread's stack?
> No rules per se, but it isn't even feasible unless the lifetimes of
> the references obey strict stack discipline
(snip)
> However, I don't see any compelling reason to permit it. The stack is
> nothing more than a compiler managed mark-release heap:
Yes. OS/360 and successors use a doubly-linked list for linkage and
register saving, and for reentrant routines usually local variables,
too.
> it's only real benefit to the programmer is no-brainer deallocation.
Non-reentrant OS/360 programs traditionally use static storage for
the save areas, which is also pretty much no-brainer. Reentrant ones
have to dynamically allocate them.
I believe that OS/360 MVT subtasks run in the same protection key
as the parent. With MVS, ordinary user tasks all run with the same
protection key, with segment and page tables updated as needed.
> Anything that might usefully be done using stack sharing can be
> done almost as easily - and much more safely - using an explicit
> mark-release heap or stacked heaps (regions, per Tofte and others).
PL/I allows for multitasking, and, as well as it can, communication
between tasks. EVENT varibles are used to synchronize, as are ECBs
(Event Control Blocks) for the OS system calls.
-- glen
[Yes, OS subtasks started with ATTACH all run in the same address
space. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.