My first question is, where did you read that, because I would like to read that too. Indeed, this is an open invitation to anyone to /msg me links to any Perl + threads articles and discussions anywhere they see them. Really. Please send me any links you have. I will even commit to producing and maintaining a list of such links, including adding some assessment rating of the information they contain.

Are you saying that ...

Whoa! I'm not saying anything that contradicts any better information you can find, or knowledge you have.

Anything I say relates only to that experience I have personally acquired--plus some speculations based upon them; other experience; and logic.

Now, getting back to what I did say:), how I arrived at that statement, and it's implications:

• In a multi-processor machine, 2 or more threads can be running simultaneously.
• With multi-tasking, Perl cannot control the point at which it is interupted by the scheduler.
• Perl's datastructures are "fat". Each one contains various attributes and flags that need to be kept in an internally consistant state.

  For example. When you append stuff to a perl scalar:

  1. the length of the scalar must be updated to reflect the addition.
  2. if the length of the C-time, memory previously allocated to that scalar is insufficient to allow the addition.
  3. then a new extended allocation must be made,
  4. and the original contents copied into it,
  5. and the addition must be copied across,
  6. and the original memory must be returned to the freespace chains.
  7. internal pointers, flags etc. all must be updated.

  This must all appear as an atomic operation from the user program's perspective.

• The scheduler can interupt any of those operations at any time.
• In a multi-cpu machine, another thread could be attempting to read, or even write that same datastructure at the same time.
• If user locking is employed purvasively, then the chances of one thread gaining access to a datastructure that is in an internally inconsistant state are nil.

Perl may use internal locking when modifying it's own internal use datastructures, such that it will prevent multiple, concurrent accesses, even if the user does not employ user locks correctly. This appears to be the case based on my experience, but I have yet to read a good description of what internal mechanisms of ithreads and sharing do, so I can only base my understanding upon my experiences, and what little I can glean from reading the sources--and that is very little! Perl's sources are scantly documented and very complicated.

The upshot of all of that is, that in my experiments with iThreads (since circa 5.8.3, on my single cpu machine), I have found it impossible to cause Perl to segfault through performing multi-threaded accesses to shared data elements even without user locks being employed. Nor have I been able to detect any inconsistancy of state.

This implies that Perl does employ internal locking to prevent internal inconsistancies, which makes sense, but I do not recall seeing this written down anywhere.

But I have not used Perl on an SMP box, so there is a chance that for all my emperical testing, I've only been "getting away with my abuse of not employing user locks consistantly", because I'm only really able to run one thread at a time.

It makes sense (to me), that Perl would employ internal locking to ensure the correct state of it's own interal structures. Which would mean that users only need to employ user locks if they are maintaining state across multiple Perl variables.

Example:. If I am using a Perl array to represent a stack, and rather than having perl remove elements "popped" from the stack, I am maintaining a separate "stack pointer" in a scalar, then when a new value is pushed to the stack, there are two operations required.

Ok, I found it. It's in the perlthrtut man page that comes with Perl 5.8.5. At the end of the section titled "Shared And Unshared Data", it says:

        Note that a shared variable guarantees that if two or more
        threads try to modify it at the same time, the internal
        state of the variable will not become corrupted. However,
        there are no guarantees beyond this, as explained in the
        next section.
[download]

And the next section describes some typical race condititons one might encounter (two threads trying to read, then increment the same variable).
So anyway, that text has led me to believe that a shared array used to implement a queue for passing data between threads would be safe, even with no locking, since the push() and shift() operations would be atomic in nature.
If this doesn't apply to SMP machines though, then I've got some code to fix...

Thankyou for taking the time to find it again.

It's also nice to have my observations confirmed, and to see that it is mentioned in the documentation somewhere.

It would be nice it also got a mention in the threads::shared POD, along with a few examples of when lock needs to be used and when not. I'll try to produce a docu-patch for that.

So anyway, that text has led me to believe that a shared array used to implement a queue for passing data between threads would be safe, even with no locking, since the push() and shift() operations would be atomic in nature.

I've generally use Thread::Queue for implementing queues between threads. I tried it early on and it has never given me a problem, so I've stuck with it.

Re-reading perlthrtut, I agree with your reading that push and shift should be safe for this purpose. I'll probably have a play and see if I can break them.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.