Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^3: is ||= threadsafe?

by ikegami (Pope)
on Oct 25, 2010 at 16:47 UTC ( #867281=note: print w/replies, xml ) Need Help??


in reply to Re^2: is ||= threadsafe?
in thread is ||= threadsafe?

It happens internally in the perl code, which is guaranteed to be thread safe

||= happens in Perl code, yet it's not thread safe for shared variables.

You may say that's because it's the user requesting a change the variable, but that's the case for all the examples I showed too.

Now, tye and BrowserUk say the shared SV is appropriately locked internally when updated (and I believe it to be true), so that eliminates the potential problems I posited, so the point is simply that your guarantee is worthless as formulated.

That's probably because you pulled the guarantee out of this air. When I looked this up some time ago, I couldn't find any documentation on this. A very quick look still shows nothing. This is why I prompted for replies on the subject.

Update: Added everything after first line.
Update: Added "for shared variables" in response to reply.

Replies are listed 'Best First'.
Re^4: is ||= threadsafe?
by BrowserUk (Pope) on Oct 25, 2010 at 17:29 UTC
    ||= happens in Perl code, yet it's not thread safe.

    You're still not getting it.

    • ||= is thread-safe, just as with any other operation--unless it is applied to a shared variable.

      That's the basic tenet of threads. Everything(*) is thread-safe unless it involves explicitly shared variables. Clear and unambiguous.

      It is the very raison d'etre of ithreads.

    • Any Perl operation applied to any shared variable is not thread-safe unless you take locks.

      That the basic tenet threads::shared. Again, clear and unambiguous.

    There is no purpose in documenting the thread-safety of every opcode--or internal operations--because they are all completely covered by those two simple tenets

    And that is what sets iThreads apart, and above, any other shared-state concurrency implementation. You use it exactly as if it was non-threaded, with no shared-state, even for the nasties of interpreted language threading--fat variables & closures. Except where you need shared-state, then you mark it explicitly and take the appropriate precautions.

    Sure, the implementation could be more efficient--of time and memory. And the user could be given finer-grained control. But for the most part, inventing a model that allows so many pre-threading modules to just work inside threads is a remarkable achievement. Even the majority of non-Pure Perl modules function perfectly within iThreads, and that's truly remarkable, and no accident.

    Artur Bergman should be lauded.

    (*)For the pedants: External state excluded.


    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.

      unless it is applied to a shared variable.

      I've only talked about shared variables.

      Any Perl operation applied to any shared variable is not thread-safe unless you take locks.

      As I understood things, tye and you said Perl did the locking for the programmer when it came to the state of the SV. Now you're saying I need to take locks myself.

        For a shared variable, each thread has a separate instance of it, each tied to a single, hidden variable that holds the value. When reading the tied variable, GET magic locks the hidden variable, copies out its value, then unlocks it. When writing the tied variable, PUT magic locks the hidden variable, replaces its value, then unlocks it. You don't need to do your own locking for threads::shared variables in the simple case.

        You need to do locking if you have more than one (GET or PUT) operation and other iThreads might do other (GET or PUT) operations in between in a way that would cause problems. ||= does two operations so it is possible that extra locking needs to be done by the user (when dealing with shared variables). This likely means that even $x++ isn't iThreads safe on shared variables (in any case, I see no evidence of extra magic being implemented in the current threads::shared to make such safe -- probably easiest to do via overloading).

        - tye        

        As I understood things, tye and you said Perl did the locking for the programmer when it came to the state of the SV. . Now you're saying I need to take locks myself.

        Now who being ... What was that word you called me?

        Perl takes care of protecting any internal changes.

        Ie. refcounts; flags; SV upgrades; UTF upgrades; anything that is not (normally) changed directly by the programmer.

        Eg, all 3 things you cited in your original post and many more.

        The programmer is responsible for locking the variable itself.


        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://867281]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2018-01-16 19:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How did you see in the new year?










    Results (188 votes). Check out past polls.

    Notices?