in reply to A faster?, safer, user transparent, shared variable "locking" mechanism.

These will only occur when writing.

The problem is, that many apparently read accesses in Perl, actually do modify the SV. Some innocent looking operations (in all example, ro is apparently read-only): 

  print $ro + 3;         #  Might upgrade a PV to a PVIV;
  $ref = \$ro;           #  Increments the refcount on $ro.
  $ro =~ /./;            #  Sets the pos associated with $ro.
  $var = $ro{foo}{bar};  #  May autovivify $ro{foo}

[download]
The fact that there are hidden data modifications is the reason that in Perl variables are by default not shared between threads.

Note also that the SV* just contain some metadata of the values - the real data is some hops away. Even something as simple as a string, with no magic attached will have its data scattered in three places (the SV* itself, containing the refcount, some flags, and a pointer to a structure (svpv) that contains, among other pieces of data, the length of the string, and a pointer to the actual string itself).

  • Comment on Re: A faster?, safer, user transparent, shared variable "locking" mechanism.
  • Download Code

Replies are listed 'Best First'.
Re^2: A faster?, safer, user transparent, shared variable "locking" mechanism.
by ikegami (Patriarch) on Oct 26, 2006 at 08:12 UTC

    The problem is, that many apparently read accesses in Perl, actually do modify the SV

    That's not a problem. The proposed locking mechanism doesn't care about appearances. If the operation involves a write, the write will trigger the locking mechanism.

    It does fail for other reasons, though.

[reply]
      Exactly. So, the system locks the SV without the programmer being aware of it. Not a problem if one thread does so, but then, no lock would have been necessary. But if two threads try to write at once, an exception will be raced. And this all happens behind the programmers back - the programmer thinks she's only doing a read access to a variable (and on a Perl level, she does), but the value is locked anyway.

      For a programmer to defend against this, she needs to know all the details of the perl internals. Which, IMO, is not a good thing. (I'm not saying it's a bad thing if more people know the internals of perl - I'm saying it's a bad thing that in order to write a good program, one has to know the internals of perl).

[reply]

        Why would a programmer need to defend against this? There's no harm (except performance-wise) in Perl locking an SV internally while it's mucking with the SV's innards.

        If two threads are mucking with the innards of the same SV at the same time, you have a huge problem. Locking the SV while mucking with the innards would solve that problem with no side-effects.

        If you already have safeguards in place to prevent the two threads from mucking with the innards of the same SV at the same time, then this internal locking is effectively a no-op.

[reply]
Re^2: A faster?, safer, user transparent, shared variable "locking" mechanism.
by BrowserUk (Patriarch) on Oct 26, 2006 at 08:21 UTC

    If shared SV*s ( and all things pointed at from them ) are allocated in the protected memory, then any write access, including those done by the system as the result of apparently read-only user code, would also trigger the exception and so be protected.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Meditations