Okay, I am not even going to attempt to engage BrowserUK in his readily-expected and intensely personal thread ... a response which I have sadly grown to expect but choose not to answer in kind.

The statement is, of course, entirely correct that concurrent access to a data structure in Perl by multiple threads will not cause the self-destruction of memory integrity as, say, the alteration of the guts of a "C" linked-list data structure might do.   The Implementors™ certainly got that much (my point #2 above) right.   But ...

My point #1 is a fundamental-design issue.   Cooperating processes/threads who are not modifying a data structure, and who never intend to modify it, nonetheless need to be safeguarded against anyone else who from time to time may wish to do so.   Otherwise, and even though the Perl (or any other...) data structures remain perfectly “intact,” they might find without warning that “reality has changed;” that the proverbial rug has just been pulled out from under them.   The concurrent readers don’t need to block one-another, but all of them do need to block (and to be blocked by) all attempted modifications.   In this way, they will properly perceive all of the groups of writes that from time-to-time do occur as being “atomic,” whether those updates consist of a single variable-update or many.

I will discuss the technical issue only to the extent necessary to clearly convey it.   I will not discuss “personalities” here, even if overtly provoked, and I would kindly ask that (the remainder of) the Community drop the subject and refuse ever to pick it up again.   We are here only to discuss the technical concerns that professionally face us all; not each another.