Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> I'd definitely rather perl not do any sort of explicit user-level locking.
>DS> That's not our job, and there be dragons.
>
>Please explain how this is possible?
>
>Does this mean that without user specifying a lock, perl will allow
>a chaotic update pattern to be visible to the user?
If the user asks for chaos, chaos is what they get.
>
> thread A thread B
> push(@foo, $bar); ++$bar;
>
>or
> $foo{$bar} = $baz; delete $foo{$bar++};
>
>Will there be some sort of coherence here?
The snag with attempting to automate such things is illustrated by :
thread A thread B
$a = $a + $b++; $b = $b + $a++;
So we need to 'lock' both $a and $b both sides.
So thread A will attempt to acquire locks on $a,$b (say)
and (in this case by symetry but perhaps just by bad luck) thread B will
go for locks on $b,$a - opposite order. They then both get 1st lock
they wanted and stall waiting for the 2nd. We are in then in
a "classic" deadly embrace.
So the 'dragons' that Dan alludes to are those of intuiting the locks
and the sequence of the locks to acquire, deadlock detection and backoff, ...
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
