locking the whole hash/ array is the only realistic possibility for the moment. but maybe some fine day in future one of the perl developers happens to stumble on this thread.

Actually, if you think about it, locking the whole hash is the only logical thing to do when modifying the hash, rather than updating things pointed at by its values.

Grr. Once again, that is about as clear as mud.

There are two types of changes that can be made to a hash:

1. Those that modify the contents of substructures pointed to from the top-level hash:

   Modifying (via reference) either the contents of %el hash or $scalar_data in your previous example fit into this category.

   For these, locking the sub-hash or scalar respectively is enough as the structure of the top-level hash does not change.

2. Those that modify the structure of the hash itself:

   Adding a new key/value pair, or deleting an existing key/value pair, and even changing the value of an existing key/value pair fit in this category.

   For these operations, it is essential that the top-level hash be locked as they change the structure of that hash itself.

   For example, adding a new key/value pair could cause the entire hash to be expanded, which involves doubling the number of buckets and re-hashing every key. Having other threads attempt to do anything with the top-level hash whilst that type of operation is in progress is a obvious no-no.

   Equally, deleting a pair will affect the operation of the each/keys/values iterators and could result in strange results unless the entire hash is locked.

   The possible consequences of modifying an individual pair value is more subtle, but if you think it through, you can see the window of opportunity for errors.