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 for some clarification here.
I think you're saying that each thread gets its own register set and
register stacks (the call chain is somewhat hidden within the register
stacks). Dan has been saying we'll do this all along.
But you're also saying that a particular PMC can only be loaded into one
register at a time, in any thread. So if thread A has a string in its
P17, then if thread B tries to load that string into its, say, P22, it
will block until thread A releases it. Is this correct?
This is a novel idea. It reduces lock acquisition/release from every
opcode to only the C<set> opcodes. That's a win.
Sadly, it greatly increases the chances of deadlocks. Take this
example:
my ($somestr, $otherstr);
sub A {
$somestr .= "foo";
$otherstr .= "bar";
}
sub B {
$otherstr .= "foo";
$somestr .= "bar";
}
Thread->new(\&A);
Thread->new(\&B);
This is a fairly trivial example, and it should work smoothly if we're
automatically locking for the user.
But consider your scheme: A loads $somestr into its P17, and performs
the concatenation. B loads $otherstr into its P17, and performs the
concatenation. A tries to load $otherstr into its P18, but blocks
because it's in B's P17. B then tries to load $somestr into its P18,
but blocks because it's in A's P17. Deadlock.
Did I accurately portray your scheme? If not, could you explain what
yours does in terms of this example?
Luke
> Regards, Nigel
