Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Threads weirdness

by reasonablekeith (Deacon)
on Jul 06, 2009 at 14:08 UTC ( #777554=perlquestion: print w/replies, xml ) Need Help??

reasonablekeith has asked for the wisdom of the Perl Monks concerning the following question:

Sorry about the vague title and the short code example, but I'm not sure what's going on here and this seems to be the crux of the matter. I have the following chunk of code.
print " -- executing: $component_name " . ($force_flag ? "(forced)" : + "") . " ($component) \n"; my $thr = threads->create( sub { my $passed_component = shift; print "STARTED: $component_name ($passed_component)\n"; $passed_component->execute($current_time); print "FINISHED: $component_name (at $current_time)\n"; }, $component );
When run it produces the following output...
-- executing: MYCOMPONENT (Scheduler::Component=HASH(0x1dd4244)) STARTED: MYCOMPONENT (Scheduler::Component=HASH(0x21bca9c))
For the life of me, I can't figure out why the two object refs are different.

It's causing a problem because the Scheduler Component object set it's last run time at the end of the execute function, but I can't see that value as I seem to be looking at the wrong object! What I'm finding even harder to understand is that I've only created one Scheduler::Component object, so have no idea where this other reference has come from.

I did put a print of $self in the new() call for Scheduler::Component, which runs before the lines shown above, and shows the value for the component outside the thread.

CREATED NEW COMPONENT (Scheduler::Component=HASH(0x1dd4244))
Any help much appreciated.
my name's not Keith, and I'm not reasonable.

Replies are listed 'Best First'.
Re: Threads weirdness
by Corion (Patriarch) on Jul 06, 2009 at 14:12 UTC

    Passing around objects among threads is fraught with potential for errors. I think the basic principle is that you'll get a copy unless you declare something as explicitly :shared. See threads and threads::shared. Personally, I'd try to decouple the scheduler from the worker(s) and have a queue in each direction to pass commands forth and receive the status (+data) back from the worker(s).

      Thanks Corion,

      The only thing that changes in the component object is the last_run_time value, so I guess you're saying I can handle that in the main thread instead of it being managed by the object, and that might fix my problem?

      I still find it very weird, as (disregarding what's in the object), that scalar ref value changes from one line to the next.

      my name's not Keith, and I'm not reasonable.
Re: Threads weirdness
by BioLion (Curate) on Jul 06, 2009 at 15:02 UTC

    The "threads get a local copy of data" bit is explained here perlthrtut, maybe reasonablekeith will find Win32::MMF::Shareable and IPC::Shareable useful too?

    I personally find the latter easier to use, but when i have to write stuff for windows, Win32::MMF is good too.

    UPDATE added the perlthrtut bit - i am trying to get to grips with threading too, and i found it useful...

    Just a something something...

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://777554]
Approved by marto
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2022-08-08 04:51 GMT
Find Nodes?
    Voting Booth?

    No recent polls found