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

Re^2: Help on Understanding Locks in Multithreading

by koti688 (Sexton)
on Feb 25, 2009 at 11:12 UTC ( [id://746223]=note: print w/replies, xml ) Need Help??


in reply to Re: Help on Understanding Locks in Multithreading
in thread Help on Understanding Locks in Multithreading

Thanks for the link.

But i studied that already and i struck with this example.

I am confused how the $foo variable is locked in the functions.

Please explain the locking in this code , if you get anything. i am asking very basic things i guess :(
  • Comment on Re^2: Help on Understanding Locks in Multithreading

Replies are listed 'Best First'.
Re^3: Help on Understanding Locks in Multithreading
by gone2015 (Deacon) on Feb 25, 2009 at 13:04 UTC

    What are you expecting, and what did you get which doesn't meet with your expectation ?

    FWIW, one wrinkle with threads is that the return context for the thread is set at threads->new time, not on the context of $thr->join(). Your code:

    $thr = threads->new(\&sub1, "THREAD1 :"); ... @ReturnData = $thr->join; ...
    should be:
    ($thr) = threads->new(\&sub1, "THREAD1 :"); ... @ReturnData = $thr->join; ...
    to provide the right context at the right time.

    The fragment:

    { lock $foo; $foo=0; }
    is reasonably plausible. You're locking $foo for just long enough to give it a new value -- so there is no possibility of some other thread attempting to read or change $foo while it's in any intermediate state -- provided they too lock $foo before doing anything with it. (The lock is dropped at the end of the block it is contained in.)

    I note that $foo is not initialised to anything.

    I note that you:

    print " Final value :$foo\n";
    without locking it. But that's probably OK, because $foo is only changed by the same thread.

    I wonder: you're not expecting $foo to work as some kind of semaphore, are you ?

Re^3: Help on Understanding Locks in Multithreading
by Wiggins (Hermit) on Feb 25, 2009 at 20:38 UTC
    I am confused how the $foo variable is locked in the functions.
    Actually '$foo' itself isn't locked, execution access is locked. By that I mean that only one thread may be executing in the code blocks that have the 'lock' command at a time. And those blocks just happening to be modifying 'foo' (well, hopefully by design). The locks are controlling/limiting execution flow to a single thread at a time. This stops 2 threads from doing near simultaneous modifications to $foo.

    In the old days this code was called a 'critical code section'.

    It is always better to have seen your target for yourself, rather than depend upon someone else's description.
Re^3: Help on Understanding Locks in Multithreading
by Anonymous Monk on Feb 25, 2009 at 12:18 UTC
    I am confused how the $foo variable is locked in the functions.
    Through the magic of perl threads? I'm sorry, I don't understand your question, but I don't think I could explain lock better than perlthrtut.

    Maybe it would be easier for you to understand if you told us where you got that code, what its supposed to do, etc?

Re^3: Help on Understanding Locks in Multithreading
by Anonymous Monk on Feb 25, 2009 at 12:20 UTC
    Try using smaller numbers, not 1000/5000

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2024-04-20 16:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found