Markus Peter wrote:
> > 6: release all mutexes when leaving it for
> > any reason (and redoing 2 through 4 on reentry)
these reasons would include doing subroutine calls.
Which makes data loss possible, without explicit mutexes
on check points and if we've got those why bother with
implied ones?
> Wouldn't this strategy not also need to track all subs called from within
> the expression to work? If not, the following thing could happen
>
> > The problem is, as long as expressions can be within each other,
> > and include terms that are multiple expressions, a robust deadlock
> > avoidance strategy is required even with cooperative threading.
> >
> > Or you can just pass the buck to the programmer, and make them use
> > explict mutexes and deadlocks while they learn.
>
> Hmm.. I fear the interpreter can never do more than to garantuee that
> certain instructions like $a=1; are atomic which could be a hard enough
> task to implement for some statements. I don't think anyone has yet found
> solutions for automatic deadlock avoidance which still allows your program
> to run at acceptable speeds.
That's what I was suggesting. And if you say $a = 1 + foo() you have
to give up your mutex on $a before calling foo(). So the programmer
would have to work these things out with the subroutines:
foo_lock();
my $b = foo();
$a = 1 + $b;
foo_unlock();
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
safety first: seat-belt wearers for Nader in 2000
