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

x = x + 1, which you've already said isn't safe

I never said that. I never implied that. For a start, what is "x"? It's not a perl variable is it. So it's just a meaningless equation.

Do I need to demonstrate further,

Yes. You need to demonstrate an actual segfault.

Why. Because what you are suggesting is possible, is IMPOSSIBLE. IT CANNOT HAPPEN.

Which makes your unfounded speculation: FUD. And, given that it is coming from you, a usually reliable and knowledgeable source, makes it dangerous and significant FUD. Possibly even deliberately malicious FUD.

So please, demonstrate your good intent by either:

  1. demonstrating a segfault using one of your original three perl statements.
  2. withdrawing the FUD.
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.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^7: is ||= threadsafe?
by ikegami (Patriarch) on Oct 25, 2010 at 05:16 UTC

    I never said that. I never implied that

    Sorry, you said ||=, not increment. I had fixed it, but too slow it seems.

    For a start, what is "x"?

    I clearly said it was the ref count.

    You need to demonstrate an actual segfault.

    Why are you playing dumb? I wasted enough time with one. You can do the others yourself.

    Which makes your unfounded speculation: FUD

    It's not unfounded. I really don't know it to be thread-safe. It's not documented anywhere, and I don't have any reason to believe it is thread safe. Even you haven't said it was.

[reply]
      I wasted enough time with one.

      Where and when? Link please?

      It's not unfounded.

      Until you demonstrate it, it is unfounded.

      and I don't have any reason to believe it is thread safe.

      You are stating on the record that you are totally unaware that Perl protects its internals with internal locking?

      You are stating outright that if I search this site I won't find a single occasion when you have indicated your knowledge of that internal locking?

      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.
[reply]

        Where and when? Link please?

        Here and now.

        Until you demonstrate it it is unfounded.

        More explicity: 

        thread 1        thread 2
--------------  --------------
tmp=refcount+1
                tmp=refcount+1
                refcount=tmp
refcount=tmp

        [download]

        The vertical axis is time.

        You are stating on the record that you are totally unaware that Perl protects its internals with internal locking?

        Yes. Are you saying it does?

        You are stating outright that if I search this site I won't find a single occasion when you have indicated your knowledge of that internal locking?

        To the best of my knowledge, yes.

[reply]
[d/l]

In Section Seekers of Perl Wisdom