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

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.

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

Replies are listed 'Best First'.
Re^3: A faster?, safer, user transparent, shared variable "locking" mechanism.
by Anonymous Monk on Oct 26, 2006 at 08:23 UTC
    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]
        I guess you've never heard about deadlocks, huh? Imagine thread "Bob" has a lock on $foo and thread "Bill" has a lock on $bar. Bob wants a lock on $bar, so he sleeps waiting for the lock. Bill wants a lock on $foo, so he sleeps waiting for $bar. Neither will ever wake up because neither lock will ever become available!

        Thread programming is hard and this is the reason!

        -sam

[reply]

In Section Meditations