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.
I think some of the massive back and forth that's going on is in part
due to terminology problems, which are in part causing some
conceptual problems. So, for the moment, let's agree on the following
things:
*) MUTEX - this is a low level, under the hood, not exposed to users,
thing that can b
