Re: Not enough parallelism in programming


nmm1@xxxxxxxxxxxxx (Nick Maclaren) writes:
> In article <s71irxsr2ah.fsf@xxxxxxxxxxxxxxxxxxxxx>,
> David Gay <dgay@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >>
> >> 2) The threads have to be such that they ARE restartable. That
> >> imposes a pretty considerable constraint on the programming paradigm,
> >> and cannot practically be done in any third generation von Neumann
> >> language, without imposing draconian restrictions.
> >
> >I think you're missing the bit about "hardware support" here. The
> >conflicts are defined in terms of virtual addresses, and the processor
> >fully supports restoring itself to an earlier state. There are a few
> >minor (well ok, not so minor) issues of course:
> >- can the hardware really rollback arbitrarily far?
> >- what about aliasing of virtual addresses to each other?
> >- what about I/O? (you mentioned that one :-))
>
> No, I didn't. You are right that they aren't minor - in particular,
> it is very likely that a thread will update a large proportion of
> its data before a conflict is discovered. That was the point of my
> remark about checkpoints.
>
> There are also non-memory CPU states (e.g. IEEE 754 modes and flags),
> signals and numerous other 'hidden' data.

Well I would presume that those ones would be handled by an in-CPU
implementation. I'm more worried about the ones outside the CPU, which
I think could all be reasonably categorised as I/O.

--
David Gay
dgay@xxxxxxx
.