On Sat, 3 Jan 2004 11:35:37 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: > Nigel Sandever <[EMAIL PROTECTED]> wrote: > > > VIRTUAL MACHINE INTERPRETER > > > At any given point in the running of the interpreter, the VM register > > set, program counter and stack must represent the entire state for > > that thread. > > That's exactly, what a ParrotInterpreter is: "the entire state for a > thread".
This is only true if a thread == interpreter. If a single interpreter can run 2 threads then that single interpreter cannot represent the state of both threads safely. > > > I am completely against the idea of VM threads having a 1:1 > > relationship with interpreters. > With 5005threads, multiple threads exist in a single interpreter. All VHLL level data is shared without duplication, but locking has to be performed on each entity. This model is more efficient than ithreads. However it was extremely difficult prevent onwanted interaction between the threads corrupting the internal state of the interpreter given the internal architecture of P5 and so it was abandoned. With ithreads, each thread is also a seperate interpreter. This insulates the internal state of one interpreter from the other but also insulates *all* perl level program data in one interpreter from the perl level data in the other. Spawning a new thread becomes a process of duplicating everything. The interpreter, the perl program, and all it existing data. Sharing data between the threads/interpreters is implemented by tieing the two copies of the variables to be shared and each time a STORE is performed in one thread, the same STORE has too be performed on the copy of that var held on every other threads dataspace. If 2 threads need to share a scalar, but the program has 10 other threads, then each write to the shared scalar requires the update of all 12 copies of that scalar. There is no way to indicate that you only need to share it between threads x & y. With ithreads, there can be no shared references, so no shared objects and no shared compound data structures > While these can be separated its not efficient. Please note that Parrot > is a register-based VM. Switching state is *not* switching a > stack-pointer and a PC thingy like in stack-based VMs. > > ... The runtime costs of duplicating all > > shared data between interpreters, tying all shared variables, added to > > the cost of locking, throw away almost all of the benefit of using > > threads. > No, shared resources are not duplicated, nor tied. The locking of course > remains, but that's it. The issues above are what make p5 ithreads almost unusable. If Parrot has found a way of avoiding these costs and limitations then everything I offered is a waste of time, because these are the issues was attempting to address. However, I have seen no indication here, in the sources or anywhere else that this is the case. I assume that the reason Dan opened the discussion up in the first place is because the perception by those looking on was that the p5 ithreads model was being suggested as the way Parrot was going to go. And the reaction from those wh have tried to make use of ithreads under p5 are all too aware that replicating them for Parrot would be ..... [phrase deleted as too emotionally charged:)] > leo Nigel.
