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

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^10: does threads (still) memleak?
by faxm0dem (Novice) on Nov 27, 2008 at 15:31 UTC
    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();
    New th2 sees all values, whereas old th1 only sees the first one:
    1$VAR1 = { 'a' => {} }; 2$VAR1 = { 'a' => {}, 'b' => {} };

      Why do you assign a nicely shared anonymous hash my $href = &share({});, and then immmediately overwrite it with a non-shared one: $href = {};?

      What you are doing is assigning a reference to a shared anonymous hash, to a non-shared scalar. You then immediately overwrite it with a reference to a non-shared anonynous hash.

      And you do a similar thing again here:

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

      It's kind of very surprising to me that anything gets shared this way(*), but if simply remove that bewildering practice, then you'll get something approaching the effect you are looking for:

      #!/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(); __OUTPUTS_ C:\test>junk1 1$VAR1 = { 'a' => {}, 'b' => {} }; 2$VAR1 = { 'a' => {}, 'b' => {} };

      That said, I don't understand why you are doing things the way you are doing them. But I realise this is just a snippet, so it might make more sense in your real code. There seems to be a tendancy to use hash refs where a simple hash would do. This is equivalent to the above, far simpler, and more reliable because perl won't let you accidently overwrite the shared hash with a non-shared one as you've been doing with the unshared reference to a shared hash.

      #!/usr/bin/perl use warnings; use strict; use threads; use threads::shared; use Data::Dumper; my %hash :shared; sub sub1 { sleep 1; print threads->tid(); print Dumper \%hash; } $hash{a} = &share({}); my $th1 = threads->new('sub1'); $hash{b} = &share({}); my $th2 = threads->new('sub1'); $th1->join(); $th2->join(); __OUTPUTS__ C:\test>junk1 1$VAR1 = { 'a' => {}, 'b' => {} }; 2$VAR1 = { 'a' => {}, 'b' => {} };

      (*)It would be interesting to see what the p5p guys make of that, cos it confuses the begebbers outta me!


      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.

        Because I stripped down the part of my code to write a test case and kept the stupid bits that I came up with some time ago to avoid "Invalid value for shared scalar" messages without understanding why they were appearing?

        Thanks a bunch I now understand my error.

        For the record, I was assigning a thread object to an element of this shared hash, and using the above "strange overwriting technique" this somehow avoided the error message. Now I'm creating a "my" object reference, share it and assign it only then to the element of the shared hash.

        Now this seems very complicated and I reckon I must have got lost somehow on the road. It's a bad idea to write production code whilst using modules for the first time, discovering design issues, circling back, discovering other issues... I think I'll start over ;-)

        Now may I use your wisdom to get a hint on how you would design the code? Here's the big picture:

        I'm simply trying to run multiple independent threads, each of which should periodically store some time-series numbers. Then a special thread would periodically take these numbers and do something with them (send them somewhere).

        What I'm doing now is start the N threads plus the sending thread. Each thread handles its own infinite loop, and with its own interval. It stores its computed numbers in this shared hash. Now when the sending thread wakes up, it locks this hash, copies it to another, empties it and unlocks it. Then it can do whatever it likes with the copy

        Regarding the corrected version of the code, I get different results randomly:
        $ ~/perl/recycleshare3 2$VAR1 = { 'a' => {} }; 1$VAR1 = { 'a' => {}, 'b' => {}, 'a' => {}, 'b' => {} }; $ ~/perl/recycleshare3 1$VAR1 = { 'a' => {}, 'b' => {} }; 2$VAR1 = { 'a' => {}, 'b' => {} };