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.

RIP an inspiration; A true Folk's Guy

unless it is applied to a shared variable.

I've only talked about shared variables.

Any Perl operation applied to any shared variable is not thread-safe unless you take locks.

As I understood things, tye and you said Perl did the locking for the programmer when it came to the state of the SV. Now you're saying I need to take locks myself.