in reply to a question on sharing data structures across threads

apparently we are digging deeper and deeper into the bouncing heart of perl itself with our discussion. i've just tested your workaround, and it worked quite fine - until: 
foreach (keys %planets) {
   lock %{$planets{$_}};
   [...]
   if ($planets{$_}->{'atime'} < $time - $some_limit) {
      delete $planets{$_}; # remove the item from cache
   }
}

[download]
obviously this cannot work, since we're having a lock on the variable in the very moment when we try to delete it, and consequently the result is: panic: MUTEX_LOCK (22) ( shared.xs:90), and as i recall to have read somewhere that lock() isn't atomic, it would be no threadsafe solution if we put the delete() outside of the lock block. seems to me that 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... ^^
--------------------------------
masses are the opiate for religion.

Replies are listed 'Best First'.
Re^2: a question on sharing data structures across threads
by BrowserUk (Patriarch) on Oct 09, 2007 at 12:38 UTC
    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.

    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]
[d/l]
[select]

In Section Seekers of Perl Wisdom