At 2:43 AM + 1/5/04, Nigel Sandever wrote:
05/01/04 01:22:32, Sam Vilain <[EMAIL PROTECTED]> wrote:
[STUFF] :)
In another post you mentions intel hyperthreading.
Essentially, duplicate sets of registers within a single CPU.
Do these need to apply lock on every machine level entity that
they a
05/01/04 04:51:20, Sam Vilain <[EMAIL PROTECTED]> wrote:
>On Mon, 05 Jan 2004 15:43, Nigel Sandever wrote;
>
> > I accept that it may not be possible on all platforms, and it may
> > be too expensive on some others. It may even be undesirable in the
> > context of Parrot, but I have seen no ar
05/01/04 04:34:15, Luke Palmer <[EMAIL PROTECTED]> wrote:
LP> I think you're saying that each thread gets its own register set and
LP> register stacks (the call chain is somewhat hidden within the register
LP> stacks). Dan has been saying we'll do this all along.
.
That has been my interpret
On Mon, 05 Jan 2004 15:43, Nigel Sandever wrote;
> I accept that it may not be possible on all platforms, and it may
> be too expensive on some others. It may even be undesirable in the
> context of Parrot, but I have seen no argument that goes to
> invalidate the underlying premise.
I th
Nigel Sandever writes:
> Whilst the state of higher level objects, that the machine level
> objects are a part of, may have their state corrupted by two
> threads modifying things concurrently. The state of the threads
> (registers sets+stack) themselves cannot be corrupted.
I'm going to ask fo
05/01/04 01:22:32, Sam Vilain <[EMAIL PROTECTED]> wrote:
[STUFF] :)
In another post you mentions intel hyperthreading.
Essentially, duplicate sets of registers within a single CPU.
Do these need to apply lock on every machine level entity that
they access?
No.
Why not?
Because they can only
On Mon, 05 Jan 2004 12:58, Nigel Sandever wrote;
> Everything else, were my attempts at solving the requirements of
> synchronisation that this would require, whilst minimising the
> cost of that synchronisation, by avoiding the need for a mutex on
> every shared entity, and the costs of a
On Sun, 4 Jan 2004 15:47:35 -0500, [EMAIL PROTECTED] (Dan Sugalski) wrote:
> *) INTERPRETER - those bits of the Parrot_Interp structure that are
> absolutely required to be thread-specific. This includes the current
> register sets and stack pointers, as well as security context
> information.
