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

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.
RIP an inspiration; A true Folk's Guy

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

    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

    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.

      Yes, none of those things are "thread safe". All of them are "iThread safe". And "Perl protects its internals with internal locking" isn't very accurate. Perl protects its internals by making full copies of its internals (the interpreter state and all data) -- emulating fork but less efficiently.

      The major thing related to iThreads that Perl protects with locking is the hidden "real value" of a threads::shared variable.

      - tye        

      Here and now.

      Update: Ah! So I wasn't "playing dumb" when I asked you to demonstrate a segfault, because you hadn't "wasted enough time with [demonstrating] one". You hadn't--and indeed haven't, and never will have--demonstrated anything except your "dumb" speculations.

      That is not a demonstration. Mearly speculation.

      A demonstration of a segfault, requires some actual code that actually segfaults.

      If you doubt this, try offering that speculation to p5p in a bug report.

      Are you saying it does?

      Yes. Perl internally locks all internal accesses to shared variable internals. See for yourself. Look for all the uses of the following two macros (amongst others):

      #define SHARED_EDIT \ STMT_START { \ ENTER_LOCK; \ SHARED_CONTEXT; \ } STMT_END /* ... then switch out and release access. */ #define SHARED_RELEASE \ STMT_START { \ CALLER_CONTEXT; \ LEAVE_LOCK; \ } STMT_END

      Even the merest modicum of rational thought would lead to the conclusion that this must be the case, and must have been the case from the very inception of ithreads, otherwise this place would have been inundated with segfault reports.

      To the best of my knowledge, yes.

      And there was me thinking I was the one with the ageing memory.


      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.

        That is not a demonstration. Mearly speculation.

        I never claimed that it was unsafe, I said I didn't know that it was safe. To support that stance, all I have to demonstrate is that it's possible that it's unsafe. That's what I demonstrated.

        If you doubt this, try offering that speculation to p5p in a bug report.

        Fallacy. I never said or implied there was a bug, so it's no surprise it wouldn't make for a good bug report.

        Yes. Perl internally locks all internal accesses to shared variable internals.

        So you knew it was thread safe, but decided to try to catch me in a non-existent lie instead saying so? wtf?