>>>>> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> my $a :shared;
>> $a += $b;
AB> If you read my suggestion carefully, you would see that I explicitly
AB> covered this case and said that the internal consistency of $a would
AB> always be maintained (it would have to be otherwise the interpreter
AB> would explode), so two threads both adding to a shared $a would result
AB> in $a being updated appropriately - it is just that you wouldn't know
AB> the order in which the two additions were made.
You aren't being clear here.
fetch($a) fetch($a)
fetch($b) ...
add ...
store($a) store($a)
Now all of the perl internals are done 'safely' but the result is garbage.
You don't even know the result of the addition.
Without some of this minimal consistency, Every shared variable even
those without cross variable consistancy, will need locks sprinkled
around.
AB> I think you are getting confused between the locking needed within the
AB> interpreter to ensure that it's internal state is always consistent and
AB> sane, and the explicit application-level locking that will have to be in
AB> multithreaded perl programs to make them function correctly.
AB> Interpreter consistency and application correctness are *not* the same
AB> thing.
I just said the same thing to someone else. I've been assuming that
perl would make sure it doesn't dump core. I've been arguing for having
perl do a minimal guarentee at the user level.
>> my %h :shared;
>> $h{$xyz} = $somevalue;
>>
>> my @queue :shared;
>> push(@queue, $b);
AB> Again, all of these would have to be OK in an interpreter that ensured
AB> internal consistency. The trouble is if you want to update both $a, %h
AB> and @queue in an atomic fashion - then the application programmer MUST
AB> state his intent to the interpreter by providing explicit locking around
AB> the 3 updates.
Sorry, internal consistancy isn't enough.
Doing that store of a value in $h, ior pushing something onto @queue
is going to be a complex operation. If you are going to keep a lock
on %h while the entire expression/statement completes, then you have
essentially given me an atomic operation which is what I would like.
I think we all would agree that an op is atomic. +, op=, push, delete
exists, etc. Yes?
Then let's go on from there.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
