Threads, Stackspace and recursion

[Jamie]

The Per Brinch Hansen is interesting and would be great for building virtual threads, however in this case using C for example it would require its own thread for allocation/deallocation.

You wouldn't need an extra thread to perform the allocation; with Brinch Hansen's method the allocate and release functions would be tacked on the beginning and end of a function definition replacing (with XS1 instructions) ENTSP and RETSP.

It's also interesting what he observes about reuse of same-sized frames - you could envisage a more extreme system where all stack frames were allocated in fixed-size blocks to reduce the allocation overhead almost entirely.

[Folknology]

Hmm what about this:

"On a multiprocessor with shared memory, the
allocation and release of activation records must be indivisible operations."

regards
Al

[Jamie]

Hmm what about this:
Quote:
"On a multiprocessor with shared memory, the
allocation and release of activation records must be indivisible operations."

You would use a lock to make them atomic.

[Folknology]

Indeed, but:
How many locks would you need?
What would the potential latencies be when locks are hit - multiple thread cycles?
And determinism slips through your hands

Although in some particular configurations this could be acceptable of course

regards
Al

[Jamie]

How many locks would you need?

One per core would do it.

What would the potential latencies be when locks are hit - multiple thread cycles?
And determinism slips through your hands

Yes, this would introduce non determinism which is why the issue is often sidestepped as it is in XC and occam. But I think this is true of dynamic allocation by it's nature, for example you get the same problems using the XS1 malloc routine with multiple threads.