Chaim Frenkel wrote:
> 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.
Because contrary to your assertion I fear it will be a special case that
will cover such a tiny percentage of useful threaded code as to make it
virtually useless. In general any meaningful operation that needs to be
covered by a lock will involve the update of several pieces of state,
and implicit locking just won't work. We are not talking syntactical
niceties here - the code plain won't work.
> It's these isolated "drop something in the mailbox" that a lock around
> the statement would make sense.
An exact definition of 'statement' would help. Also, some means of
beaming into the skull of every perl6 developer exactly what does and
does not constitute a statement would be useful ;-) It is all right
sweeping awkward details under the rug, but make the mound big enough
and everyone will trip over it.
> my $a :shared;
> $a += $b;
If you read my suggestion carefully, you would see that I explicitly
covered this case and said that the internal consistency of $a would
always be maintained (it would have to be otherwise the interpreter
would explode), so two threads both adding to a shared $a would result
in $a being updated appropriately - it is just that you wouldn't know
the order in which the two additions were made.
I think you are getting confused between the locking needed within the
interpreter to ensure that it's internal state is always consistent and
sane, and the explicit application-level locking that will have to be in
multithreaded perl programs to make them function correctly.
Interpreter consistency and application correctness are *not* the same
thing.
> my %h :shared;
> $h{$xyz} = $somevalue;
>
> my @queue :shared;
> push(@queue, $b);
Again, all of these would have to be OK in an interpreter that ensured
internal consistency. The trouble is if you want to update both $a, %h
and @queue in an atomic fashion - then the application programmer MUST
state his intent to the interpreter by providing explicit locking around
the 3 updates.
--
Alan Burlison
