On Fri, 18 Aug 2000, Steven W McDougall wrote:
> Thread1 Thread2
> push @a, (1, 2, 3); push @a, (4, 5, 6);
>
> The interesting question is whether push is atomic.
Array operations should be atomic.
>
> Atomic
> @a is either (1, 2, 3, 4, 5, 6) or (4, 5, 6, 1, 2, 3)
Yes.
>
> Non-atomic
> @a could be (1, 4, 2, 5, 3, 6)
Icky-poo.
>
> Users can probably live with either; the hard problems are
> implementation under SMP. If push is atomic, then we lock out one
> processor for a potentially long time while the other processor
> executes the push. If push isn't atomic, then we enter and leave a
> critical section once for each element that is pushed.
I'd prefer the first. (I'd rather wait for somewhat sane results than
fly through with randomness.)
>
>
> 3. Subroutines
>
> sub foo { print "foo" }
>
> Thread1 Thread2
> foo(); eval 'sub foo { print "bar" }';
>
> This prints either "foo" or "bar".
>
> Thread2 replaces the coderef for &main::foo. This could happen *while*
> Thread1 is executing foo(). We can handle this by having Thread1 hold
> a reference count on the coderef while it is executing foo().
Hadn't considered this. Hmmm....
>
>
> 4. Regular expressions
>
> Thread1 Thread2
> $a =~ /.../ $a = 'foo';
>
> It seems like an RE match should be atomic, because it hard to imagine
> it executing sensibly if the target string changes during the match.
> But then we have
>
> $a =~ s/.../.../e; $a = 'foo';
>
> s///e can execute arbitrary code, so if s// is atomic, then Thread2
> could be blocked for an arbitrary length of time.
Hmmm again, although, once again, I'd sacrifice time.
Of course, both require a more complex locking mechanism than simple
variable access, which can lead to some pretty hairy situations.
(Assuming all program globals, of course.)
Thread 1: $a = $b + $c;
Thread 2: $d = $c / $a;
Thread 1, doing statement locking, could lock these $a, $b, $c, while
Thread 2 locks them $d, $c, $a. Potential deadlock between $a and $c.
>
> - SWM
--
Bryan C. Warnock
([EMAIL PROTECTED])
