Re^7: is ||= threadsafe?

[ikegami]

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.

[BrowserUk]

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?

[ikegami]

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.

[tye]

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.

[BrowserUk]

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.