Re: Question about inter-thread stack references

Interestingly, the answers I have gotten here (thank you all) have been
all over the lot, from required to forbidden and all points between.


Some explanation:


As Stefan guessed, my question does in fact arise from architectural
issues on the Mill. The Mill design goes to considerably greater
lengths in support of program reliability than most, and in particular
the Mill attempts to do as much sanity-checking of the executing
program that it can, consistent with hardware and execution cost. It
is tighter on issues that impact security, but also tends to nanny on
issues that are not obvious vulnerabilities but are nevertheless
semantically invalid. The concern is in part philosophical and in
part because we feel reliability is something that can be marketed
when we have product. Crassly commercial I know, but there it is :-)


One way the reliability concern surfaces is in checking for invalid
references to memory. Mill memory checking is to the byte, not to the
page; it is possible to grant access to a one byte object to some
process without allowing access to adjacent bytes. This might be used
to give a device driver access to a single register in MMIO space
without also giving it the ability to trample over the rest, as is so
often the root cause of OS crashes.


To support limited access, the hardware contains special facilities to
track the current size of the running stack as that changes with call
and return operations. As a result, and unique to the Mill as far as I
know, a function that returns a pointer to an activation-local object
will cause a segv when the caller dereferences that pointer. The stack
rubble of prior activations is not in the address space of the
executing thread. The check is in hardware, transparent, and cheap,
and so is consistent with the Mill design philosophy, as described.


However, the hardware check can only track one stack. If there are two
threads, each running in their own core, then each will be checked
w/r/t their own accesses, but we would like to check the accesses from
each to the others' stack too. Unfortunately, despite a lot of head
scratching, we have found no way to do inter-thread checks that is not
intrusive and/or expensive.


However, it would be trivial to simply ban inter-thread references
outright using the existing checking logic. Were we to do so, we could
define the ABI so as to require the compiler to detect references to
stack-allocated objects that leak from the stack and either issue a
diagnostic or automatically place them on the heap, as is often done
now for all alloca() calls on some systems. Unfortunately, C and
pointer analysis do not make good bed-fellows, and we doubt that
compilation-based techniques will be universally effective. As a
result, we fear that an inter-thread reference ban will break existing
programs, and forcing rewrite is very much not something we want to
do.


So I asked here what the experience was with inter-thread stack
references, in hopes that the issues (which clearly impact how garbage
collection can be implemented for example, where stacks must be
searched for roots) might have been previously addressed by others in
the field and possibly might even have been baked into languages or
prior architectures. Apparently not, at least as far as the expertise
here reports.


Can any of you suggest some other board or venue where I could repeat my
question usefully?


Thank you again for your help.


[I'd look at the programming models people use for threads, notably
POSIX pthreads and MIT/Intel Cilk. You'll generally find that threads
are managed in a tree, with a routine which may itself be a thread
starting up subthreads and then waiting for them and cleaning up. So
it is common for a thread to access data in the threads above it in
the tree, passed as arguments, but considerably less common to have
cross-tree or downward accesses. You might ask in places where people
who do high performance numeric computing hang out, since that's all
heavily parallel and usually threaded these days. -John]

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