Nigel Sandever <[EMAIL PROTECTED]> wrote: > On Sat, 3 Jan 2004 21:00:31 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote: >> Yep. So if a single interpreter (which is almost a thread state) should >> run two threads, you have to allocate and swap all.
> When a kernel level thead is spawned, no duplication of application memory > is required, Only a set of registers, program counter and stack. These > represent the entire state of that thread. Here is the current approach, I've implemented partly: The state of a thread is basically the interpreter structure - that's it. In terms of Parrot at thread (a ParrotThread PMC) is derived from an interpreter (a ParrotInterpreter PMC). Please remember, Parrot is a register based VM and has a lot of registers. The whole representation of a VM thread is more and different to a kernel thread. While scheduling a kernel thread is only swapping above items, a VM level thread scheduler would have to swap much more. > If a VM thread mirrors this, by duplicating the VM program counter, > VM registers and VM stack, then this VM thread context can also > avoid the need to replicate the rest of the program data (interpreter). You are again missing here: the interpreter is above VM state - the rest is almost nothing. So the interpreter := thread approach holds. You can't run a even a single - the one and only - thread without these necessary data and that's just called interpreter in Parrot speak. > ... No need for :shared or lock(). That's the - let's say - type 4 of Dan's layout of different threading models. Everything is shared by default. That's similar to the shared PMC type 3 model - except that no objects have to be copied. It for sure depends on the user code, if one or the other model will have better performance, so the user can choose. We will provide both. > Only duplicating shared data on demand (COW) may work well on systems > that support COW in the kernel. No, we are dealing with VM objects and structures here - no kernel is involved for COWed copies of e.g. strings. [ snips ] > Each element, the seraration of the VMstate from the interpreter state, VM = Virtual machine = interpreter These can't be separated as they are the same. > the atomisation of VM operations, Different VMs can run on different CPUs. Why should we make atomic instructions out if these? We have a JIT runtime performing at 1 Parrot instruction per CPU instruction for native integers. Why should we slow down that by a magnitude of many tenths? We have to lock shared data, then you have to pay the penalty, but not for each piece of code. > You only need to copy them, if the two threads can attempt to modify > the contents of the objects concurrently. I think, that you are missing multiprocessor systems totally. leo
