Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: is ||= threadsafe?

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


in reply to is ||= threadsafe?

I don't know any of the following to be thread-safe:

$shared = "abc"; # Can cause scalar type conversion my $ref = \$shared; # Increments ref count print "$shared\n"; # Implicit type conversion

Update: They are thread-safe. See Re^10: is ||= threadsafe? (threads != iThreads, "locking")

Replies are listed 'Best First'.
Re^2: is ||= threadsafe?
by perl-diddler (Chaplain) on Oct 25, 2010 at 10:16 UTC
    But the increment doesn't happen in user code. It happens internally in the perl code, which is guaranteed to be thread safe (unless there is a bug). So this wouldn't be an issue. the issue I queried about is not, clearly, something that is internal, but is a short hand for a user-land test and then set, thus while it *could* be optimized, I sorta doubted it, but thought I'd check.

    The case you are talking about would imply a bug in perl in it not being thread safe, since variable reference counts are not user-land features, but things handled automatically by perl -- so they are inherently thread-safe as much as perl is defined to be thread-safe.

    That said, I'm sure you'd have to protect such increments from multi-threaded access, inside perl, but that's not something we need to worry about in userland.

      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.

        ||= 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.
Re^2: is ||= threadsafe?
by BrowserUk (Pope) on Oct 25, 2010 at 03:55 UTC

    Without contesting any of those in any way whatsoever, can you suggest possible scenarios in which they might cause some kind of problem?

      segmentation fault, premature deallocation and segmentation fault (respectively) are serious problems in any scenario.
        segmentation fault, premature deallocation and segmentation fault (respectively)

        I challenge you to demonstrate any one of those.

        And when you can't, come back and I'll explain why you can't.

Re^2: Utter FUD!
by BrowserUk (Pope) on Oct 25, 2010 at 08:55 UTC

    Admittedly, I have only waited roughly an hour for this to run, but that is sufficient for 100 threads to explore the possibilities of each your speculative modes of failure, for 100 million plus iterations each. (Ignoring all the other threaded code I've ever written that could have done so)

    I consider that a pretty conclusive demonstration that you're talking out your a the top of your head.

    Of course you could have tried this trivial test of your speculations yourself, in the same minimal amount of time, before posting such FUD, but that wouldn't meet your apparent motivations.


    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.

      Yeesh, what's with all the hostility?

      See Tye's buried node for a sensible answer. Unfortunate that it wasn't posted at a more visible depth.

        See Tye's buried node

        No point in even looking. It'll just be more uniformed, unfounded FUD based on nothing more than supposition and rumour.

        Yup! Just as I suspected.


        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.

      Stop pretending I said it was unsafe.

      The idea is that someone would indicate if it was or not. It would have taken 30s of my time and 30s of theirs.

        Stop pretending I said it was unsafe.

        I'll let others judge for themselves what was implied by what you said.

        Had you asked a question, rather made an ambiguous and highly suggestive statement, we would not be having this discussion.

        someone would indicate if it was or not.

        I had already answered the OP question 1hr 27 minutes before you posted.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://867127]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2018-07-16 18:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?















    Results (346 votes). Check out past polls.

    Notices?