[e-lang] Multi-Core Processor Software

[David Hopwood]

I wrote:
> OTOH, I don't think that automatic parallelisation is really necessary.
> I think that manually breaking up programs to use a larger number of vats
> is likely to be quite feasible in most cases. Perhaps allowing limited
> use of shared-state Software Transactional Memory (e.g. allowing *some*
> objects to be explicitly shared between vats and atomically updated) would
> make that easier.

This needs a bit more explanation. Suppose that you can *almost* split
vat A into two vats B and C. However, there was some object-abstraction
'foo' in A that would need to be accessed by both B and C.

In the pure event-loop model, there is no obvious way to perform this
split without having to redesign at least some of the code that accessed
'foo'. You can put 'foo' in, say, vat B, and require its accessors that
are now in vat C to communicate with vat B, or you can split it into two
"presences" 'foo_B' and 'foo_C', and try to maintain synchronization
between them.

In the code before the split, it will have been assumed -- maybe implicitly --
that any synchronous operation that accesses 'foo' cannot be interrupted by
a turn boundary. Regardless of how 'foo' is split, the code that made these
assumptions will have to be carefully reviewed to check that it is still
correct, which is an error-prone process that, even if no mistakes are made,
increases the difficulty of the splitting.

If we allow 'foo' to be shared and *atomically* updated by either B or C,
then the split becomes much easier. This can be implemented (I think) in
such a way that the overhead of maintaining read conflict sets usually
associated with STM, is only incurred for shared objects, not for any
other object.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>