At 10:53 PM 9/5/00 -0400, Chaim Frenkel wrote:
> >>>>> "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?
What, perl not make any locks automatically that are visible to the user?
That's easy. :)
>Does this mean that without user specifying a lock, perl will allow
>a chaotic update pattern to be visible to the user?
>
> thread A thread B
> push(@foo, $bar); ++$bar;
>
>or
> $foo{$bar} = $baz; delete $foo{$bar++};
Yup. Ask for random behaviour, get random behaviour. Nondeterminancy can be
*such* fun...
>Will there be some sort of coherence here?
Well, there'll be safe access to individual variables when perl needs to
access them, but that's about it.
Some things we can guarantee to be atomic. The auto increment/decrement
operators can be reasonably guaranteed atomic, for example. But I don't
think we should go further than "instantaneous access to shared data will
see consistent internal data structures".
I don't even want to take things out a step to guarantee atomicity at the
statement level. There are speed issues there, since it means every
statement will need to conditionally lock everything. (Since we can't
necessarily know at compile time which variables are shared and which
aren't) There are also lock ordering issues, which get us deadlock fun.
And, of course, let's not forget some of the statements can last a *long*
time and cause all sorts of fun--eval comes to mind, as do some of the
funkier regex things.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
