Re: threads::shared - when to lock a hash ?

A shared resource, whether a variable or not, must be locked “anytime.” It is not merely to ensure that the value is not physically destroyed. There are two use-cases that must be guarded; they are separate but related.

Read stability: This is the “write once, read many” locking scenario. Many processes, all of whom are “merely reading” a shared resource, need to block anyone else from making a modification at the same time, although they don’t care how many others may be reading.
Write stability: The more-obvious requirement. Processes that are updating a resource need to avoid race conditions that could cause the value to be destroyed ... whether in the literal sense of data-structure destruction or simply in the sense of unpredictable (and therefore, useless) final values. This lock is exclusive and cannot be obtained until all other write and read locks are satisfied.

The first requirement, not merely the second one, dictates the true and comprehensive need for locking. It applies not only in the Perl environment but also in every other situation.

Effective locking can be voluntary, e.g. the SELECT LOCK(name) capability of MySQL. If there is known to be complete and full-coverage cooperation among all possible accessors of a resource, process synchronization can be achieved by placing locks upon a pool of arbitrarily-named strings, provided that the protocol for constructing those strings is carefully and completely known by all.

Replies are listed 'Best First'.
Re^2: threads::shared - when to lock a hash ? by BrowserUk (Patriarch) on Oct 16, 2011 at 14:19 UTC
The first requirement ... dictates the true and comprehensive need for locking. It applies not only in the Perl environment but also in every other situation. You're at it again. Spouting utter twaddle! Even in the face of prior authoritative information in this thread by the man that knows. For any value that can be read & written atomically -- which, for example in C on a 64-bit processor, includes all suitably aligned integers, floating point values and addresses up to 64-bits in length -- locking is unnecessary for reading or writing. And in the case of Perl and threads::shared, scalar variables -- including those embedded within hashes or arrays -- can be read at any time without locking. Even if another thread is attempting to modify that same scalar. You will either get the value before the writer writes, or you'll get the value after it has written. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' 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.	[reply]
Re^2: threads::shared - when to lock a hash ? by Anonymous Monk on Oct 17, 2011 at 02:53 UTC
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.	[reply]
Re^3: threads::shared - when to lock a hash ? by locked_user sundialsvc4 (Abbot) on Oct 17, 2011 at 02:55 UTC
The above reply, of course, was mine. PerlMonks timed out on me. I think that nothing more need be said ... or, should be said. Please. And, if anything else “personal” is said, I shall never reply to it.