Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Shareable objects.

by renodino (Curate)
on Sep 05, 2007 at 15:58 UTC ( #637191=note: print w/ replies, xml ) Need Help??


in reply to Shareable objects.

I guess I don't understand your problem statement ? As threads::shared provides its own bless() implementation, it is certainly quite possible to bless shared variables.

Here's an updated version of your example using stock threads::shared and a regular hashref object. It adds a wrinkle in order to more thoroughly test a perceived limitation: rather than creating the shared object prior to spawning threads - which will automatically clone the shared object into all threads -, this example creates the object after the threads are spawned, and passes the object to each thread via a Thread::Queue:

package dummy; use threads; use threads::shared; use strict; use warnings; sub new{ my %self : shared = qw[ there are some parameters here 1 ]; return bless \%self, $_[0]; } sub get{ my $self = shift; @{ %$self }{ @_ || sort keys %$self } ; } sub put{ my $self = shift; lock %$self; $self->{ +shift } = shift while @_; } package main; use threads; use threads::shared; use Thread::Queue; use strict; use warnings; our $N ||= 10; sub t { my ($q) = @_; my $tid = threads->self->tid; my $obj = $q->dequeue(); sleep 1; warn "$tid: ", join'|', $obj->get(), $/; sleep rand 10; $obj->put( $tid, $tid ); warn "$tid: ", join'|', $obj->get(), $/; } my $q = Thread::Queue->new(); my @t = map{ threads->create( \&t, $q ) } 1 .. $N; my $obj = new dummy; print join '|', $obj->get, $/; $q->enqueue( $obj ) for @t; $_->join for @t; print join '|', $obj->get; _END_ C:\Perl>perl globthrd.pl 1|parameters|are| 1: 1|parameters|are| 2: 1|parameters|are| 3: 1|parameters|are| 4: 1|parameters|are| 5: 1|parameters|are| 6: 1|parameters|are| 7: 1|parameters|are| 8: 1|parameters|are| 9: 1|parameters|are| 10: 1|parameters|are| 3: 3|1|parameters|are| 1: 1|3|1|parameters|are| 4: 1|3|4|1|parameters|are| 8: 1|3|4|8|1|parameters|are| 9: 1|3|4|8|9|1|parameters|are| 5: 1|3|4|5|8|9|1|parameters|are| 7: 1|3|4|5|7|8|9|1|parameters|are| 10: 1|10|3|4|5|7|8|9|1|parameters|are| 2: 1|10|2|3|4|5|7|8|9|1|parameters|are| 6: 1|10|2|3|4|5|6|7|8|9|1|parameters|are| 1|10|2|3|4|5|6|7|8|9|1|parameters|are
As to the reasons for using the master/proxy (aka apartment threaded) architecture, that isn't really about the ability (or not) of passing blessed shared objects around, but rather, a way to
  1. support legacy, possibly threads-hostile modules (e.g., DBI => DBIx::Threaded, Tk => Tk::Threaded, etc.)
  2. simplify the mapping of concurrency onto component-oriented architectures, thereby reducing/eliminating the need for component authors to get distracted by tangential complexities (e.g., maintaining state machines), possibly resulting in nicely shared-nothing architectures.
Indeed, in complex apps, both shared objects (as "resources"1) and apartment threaded objects (as "actors") are often needed.

Perhaps you could more precisely explain the problem you're trying to solve ?

Update:
One other (esoteric) differentiator for apartment threading vs. threads::shared objects:
the objects inside apartment threads don't need to be threads::shared, which means they access their members directly wo/ any locking (explicit or implicit). threads::shared objects have to navigate the "dead whale" (aka the global shared interpretter lock) for every member access...which may often (usually?) mean that they're going to take that context switch hit anyway...and possibly far more frequently than the apartment threaded alternative. So, in moderately threaded applications, the performance difference may be negligible.

1. Some will argue that resources can/should also be apartment threaded in container objects to preserve shared-nothingness.


Perl Contrarian & SQL fanboy


Comment on Re: Shareable objects.
Download Code
Re^2: Shareable objects. (Updated)
by BrowserUk (Pope) on Sep 05, 2007 at 16:20 UTC
    As threads::shared provides its own bless() implementation,

    Hm. And when did that happen?

    From the threads::shared POD:

    BUGS

    bless is not supported on shared references. In the current version, bless will only bless the thread local reference and the blessing will not propagate to the other threads. This is expected to be implemented in a future version of Perl.

    I guess I don't understand your problem statement ?

    How about this this "problem statement", and this "problem statement", and oh, say two dozen more posts here that have asked for this or cited this restriction as a reason for not using iThreads?


    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.
      As threads::shared provides its own bless() implementation,

      Hm. And when did that happen?

      From the threads::shared POD: ...

      I don't know precisely when, but its in the code. You can go look it up yourself. Just grab threads::shared from CPAN, and open shared.xs in the editor of your choice. I'll leave it to you to do the backtracking to see when it showed up.

      As to the bug, I believe it now refers only to passing a variable from thread A to thread B, wherein thread B bless()es it. Thread A's version won't get its proxy's stash updated, ergo, thread A doesn't know its been blessed. However, if thread B passes the object back to thread A, A will get a new blessed copy. IOW, when a new proxy instance of a shared variable is created, any blessing the "real" version has inside the shared interpretter is propagated to the new proxy. (Thats the reason for thread::shared's bless() override: to put the package in the shared interpretter's stash). But since the thread that's blessing doesn't know anything about the other thread's existance, much less having direct access to its private interpretter, the new blessing can't be propagated. Presumably, a solution could be provided that would check a variable's shared interpretter stash and keep it in sync with private proxy versions on every access...but threads::shared has enough performance issues in that regard wo/ piling on something thats likely very rare, and can probably be worked around.

      The only other issue I'm aware of is if thread A creates an object from a package that it "require"s internally, but which is not require'd in a thread to which the object is passed. In that instance, the receiving thread doesn't have the package info in its thread-private interpretter, and so it chokes on any object references.

      Well, and maybe the inconvenience that any refs assigned to shared object members must themselves be shared. But thats a general groundrule, not unique to shared objects.

      As to the provided links, I'll can only state that I haven't time at the moment to follow every thread on perlmonks to their final conclusion.

      Perhaps the threads::shared docs need some clarification, and the blessing of shared objects needs to be evangelized better ?


      Perl Contrarian & SQL fanboy
        Just grab threads::shared from CPAN,

        I already had it, and your code worked without me doing anything. But I woudl never had thought to try it because I knew it didn't work. I tried many times a long time ago. 'sides, the docs told me ot wouldn't

        Perhaps the threads::shared docs need some clarification, and the blessing of shared objects needs to be evangelized better ?

        If two of the most informed monks here didn't know about it, and if I, who may know nothing but do read anything and everything I see regarding threads, hadn't seen a single reference to it, then a little mention somewhere would be good thing I think :)


        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://637191]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (13)
As of 2014-10-30 13:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (208 votes), past polls