Re: Question about inter-thread stack references

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Sun, 18 Jan 2015 21:47:49 +0000 (UTC)

          From comp.compilers

Related articles
[2 earlier articles]
Re: Question about inter-thread stack references lkrupp@nospam.pssw.com.invalid (Louis Krupp) (2015-01-16)
Re: Question about inter-thread stack references gah@ugcs.caltech.edu (glen herrmannsfeldt) (2015-01-17)
Re: Question about inter-thread stack references gneuner2@comcast.net (George Neuner) (2015-01-18)
Re: Question about inter-thread stack references monnier@iro.umontreal.ca (Stefan Monnier) (2015-01-18)
Re: Question about inter-thread stack references kaz@kylheku.com (Kaz Kylheku) (2015-01-18)
Re: Question about inter-thread stack references ivan@ootbcomp.com (Ivan Godard) (2015-01-18)
Re: Question about inter-thread stack references gah@ugcs.caltech.edu (glen herrmannsfeldt) (2015-01-18)
Re: Question about inter-thread stack references gah@ugcs.caltech.edu (glen herrmannsfeldt) (2015-01-18)
Re: Question about inter-thread stack references jgk@panix.com (2015-01-25)
Re: Question about inter-thread stack references kaz@kylheku.com (Kaz Kylheku) (2015-01-25)
Re: Question about inter-thread stack references jgk@panix.com (2015-01-27)
| List of all articles for this month |

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]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.