Re: Thread usage cases

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])