Re^2: threads::shared variables not really shared... or are they?

The original added 100 1Mbyte strings to @a. Your example adds 50 * 10 = 500 1Mbyte strings to @a. Also, each thread will create a 1Mbyte private scalar; the original only created a single big string.

(The lack of locks is a bit troubling, but the aforementioned global interpretter lock is probably keeping your example out of trouble)

Perl Contrarian & SQL fanboy

Comment on Re^2: threads::shared variables not really shared... or are they?

Replies are listed 'Best First'.
Re^3: threads::shared variables not really shared... or are they? by zentara (Cardinal) on Mar 08, 2008 at 18:47 UTC
Ooops, you are right, this one gives memory use that agrees with the OP's original script. I think the sleep calls prevent the locking problem. At least on a faster machine. :-) `#!/usr/bin/perl use threads; use threads::shared; my @a : shared; for (1..10) { sleep 1; threads->new(\&foo); } sleep 1; system "grep VmSize /proc/$$/status"; <>; sub foo { for (1..10) { push @a, " " x 1e6; } print @a . " elements in \@a\n"; }` [download] I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: threads::shared variables not really shared... or are they?
by zentara (Cardinal) on Mar 08, 2008 at 18:47 UTC

#!/usr/bin/perl
use threads;
use threads::shared;

my @a : shared;

for (1..10) { 
   sleep 1;
   threads->new(\&foo); 
   }

sleep 1;
system "grep VmSize /proc/$$/status";
<>;

sub foo {
   for (1..10) { push @a, " " x 1e6; }
   print @a . " elements in \@a\n";
}
[download]

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

[reply]
[d/l]