in reply to Re^6: does threads (still) memleak?
in thread does threads (still) memleak?

One thing. In my example, for the sake of simplicity, I use printf from multiple threads, without any form of locking. I can get away with this, as long as the output is going to the screen, because on my system the OS serialises the output.

If your system doesn't do this, or (for example) if you want to be able to re-direct the output file, then you should (I should) be using a semaphore. A simple way to do that is to wrap print/printf something like: 

my $stdOutSem :shared;
sub tprint {
    lock $stdoutSem;
    print ref( $_[0] ) eq 'GLOB' ? shift() : () "[@{[ threads->tid ]}]
+:", @_;
}

sub tprintf {
    lock $stdoutSem;
    printf ref( $_[0] ) eq 'GLOB' ? shift() : () "[%s]" . $_[0], $_[ 1
+ .. $#_ ];
}

[download]

Refactor and season to taste.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^8: does threads (still) memleak?
by faxm0dem (Novice) on Nov 27, 2008 at 14:45 UTC
    First of all, thanks for your helpful examples. I am now recycling threads in my code, but I ran into the following new problem: How do I share new data between old threads?
[reply]
      How do I share new data between old threads?

      Hm. That is a very ambiguous question. Essentially, all shared variables are accessible from all threads. So, as soon as you assign a new value to an existing shared variable, it (the new value), becomes available to all other threads the next time they get a timeslice.

      Of course, that then raises the questions:

      1. How do the other threads know there is a new value is available in an existing shared var?
      2. How does the particular thread (or set of threads) know that the new value is intended for them?

      One way to notify threads of the availability of new values is to use the cond_* functions in threads::shared, but that is often the hardest and most error prone way of doing things. There are all sort of caveats to do with missed signals, deadlocks etc. Thread::Queue is usually far easier to both use, and to reason about.

      To be able to give you a good answer to the problem underlying your question, we would need to know a little more about that problem. I can sit here and try t dream up scenarios for what you are trying to achieve, and come op with half a dozen that would all completely miss the mark. In other words, please post a little code demonstrating the problem you are trying to tackle, then we stand a better than even chance of offering you an appropriate solution.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
        I'm sharing nested hashes. Now when a new element becomes available, the old threads don't see it: 
        #!/usr/bin/perl

use warnings;
use strict;
use threads;
use threads::shared;
use Data::Dumper;

my $href = &share({});
$href = {};

sub sub1 {
  sleep 1;
  print threads->tid();
  print Dumper $href;
}

$href->{a} = &share({});
$href->{a} = {};

my $th1 = threads->new('sub1');
$href->{b} = &share({});
my $th2 = threads->new('sub1');

$th1->join();
$th2->join();

        [download]
        New th2 sees all values, whereas old th1 only sees the first one: 
        1$VAR1 = {
          'a' => {}
        };
2$VAR1 = {
          'a' => {},
          'b' => {}
        };

        [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom