>>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> The problem with saying that perl should ensure that the operation "$a =
AB> $a + $b" is atomic is that it is an unbounded problem. When should $a
AB> be automatically locked and unlocked? At the beginning and end of the
AB> += op? at the beginning and end of the line? the block? the sub? You
AB> get my point - in general it is impossible to know the intent of the
AB> programmer with respect to how long he requires exclusive use of $a.
AB> That's why threaded programs use explicit locks - they are how the
AB> programmer tells the machine that he wants everyone elses hands off of a
AB> piece of shared state. I'm sure that you can see the potential
AB> difference in the outcome of the following two bits of code:
I'd like to make the easy things easy. By making _all_ shared variables
require a user level lock makes the code cluttered. In some (I think)
large percentage of cases, a single variable or queue will be use to
communicate between threads. Why not make it easy for the programmer.
It's these isolated "drop something in the mailbox" that a lock around
the statement would make sense.
my $a :shared;
$a += $b;
my %h :shared;
$h{$xyz} = $somevalue;
my @queue :shared;
push(@queue, $b);
Multi-variable consistance would not be guarenteed, use of a lock()
in the current scope would turn of the auto-locking.
If this is still too much, would an attribute be acceptable?
my $a :shared, autolock;
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
