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

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.

Replies are listed 'Best First'.
Re^10: is ||= threadsafe? (threads != iThreads, "locking")
by tye (Sage) on Oct 25, 2010 at 13:54 UTC

    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        

Re^10: is ||= threadsafe?
by BrowserUk (Patriarch) on Oct 25, 2010 at 05:44 UTC
    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?

        I said I didn't know that it was safe.

        I don't know for sure that when Perl is run on *nix, it doesn't irradiate kittens in the third world, but I don't go around posting such non-information in response to every Perl on Linux question that arises here.

        I never said or implied there was a bug.

        If what you speculated was true--it would be a bug. A bug so common that it would obvious to anyone who spends as much time here as you do.

        The fallacy is the idea that such obvious possibilities were not a fundamental part of the design from the outset.

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

        It was possible that you knew of an obscure bug that I have never heard of--it has happened several times before.

        Hence my initially asking for further information. From there, (minus the bits you indelibly erased) ... is on the record.


        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.