Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Sharing Package variables across threads

by metaperl (Curate)
on Aug 31, 2011 at 20:19 UTC ( #923505=perlquestion: print w/replies, xml ) Need Help??
metaperl has asked for the wisdom of the Perl Monks concerning the following question:

When using threads::shared what happens with package variables across threads? The docs make it clear that lexical variables have to be shared or they will be copied. But it says nothing about package variables. Since all data is copied in different threads, I'm not sure:
  1. whether shared is reserved for lexical variables
  2. whether different things occur for package variables based on whether or not they are shared

Replies are listed 'Best First'.
Re: Sharing Package variables across threads
by ikegami (Pope) on Aug 31, 2011 at 20:26 UTC

    threads::shared has no effect on variables, package or otherwise.

    The question is really whether you can make a shared package variable. share doesn't say it only works on lexical variables.

    Let's try it to confirm:

    $ perl -Mthreads -Mthreads::shared -E' share($x); $x = 4; async { say $x; ++$x; }->join; say $x; ' 4 5

    So yes, you can.

    Sharing adds magic to a variable, and thread cloning handles variables with this magic specially. It doesn't care whether the variable is accessible via the symbol table (package variable), via a function's pad (lexical variable), both or neither.

        Yes, but since the threads are in the same process, when a new thread is made, are copies made of package variables also if they arent marked as shared? I'm sorry for these "dumb" questions, but the idea of two threads in the same process is a bit confusing to me.

        perlthrtut#Shared And Unshared Data
        by default, no data is shared.
        When a new Perl thread is created, all the data associated with the current thread is copied to the new thread, and is subsequently private to that new thread!
        In computer science, a thread of execution is the smallest unit of processing that can be scheduled by an operating system. It generally results from a fork of a computer program into two or more concurrently running tasks. The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process. Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources. In particular, the threads of a process share the latter's instructions (its code) and its context (the values that its variables reference at any given moment). To give an analogy, multiple threads in a process are like multiple cooks reading off the same cook book and following its instructions, not necessarily from the same page.
        perlthrtut#What Is A Thread Anyway?
        A thread is a flow of control through a program with a single execution point.

        Sounds an awful lot like a process, doesn't it? Well, it should. Threads are one of the pieces of a process. Every process has at least one thread and, up until now, every process running Perl had only one thread. With 5.8, though, you can create extra threads.

        Come on, bud, try it! You even have the code already, you just need to remove the call to share.

        the idea of two threads in the same process is a bit confusing to me.

        Don't you mean "the idea of threads is a bit confusing to me"?

        Threads are always in the same process. One never deals with threads in other processes.

Re: Sharing Package variables across threads
by zentara (Archbishop) on Sep 01, 2011 at 10:06 UTC

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://923505]
Approved by ikegami
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2017-01-18 09:04 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (161 votes). Check out past polls.