Such a mechanism cannot replace user-level locks. (By that I mean something like thread::shared::lock.)
It doesn't allow the locking to span more than one op, so operations which both read and write to a variable (such as $s = $s + 1) still result in a race condition.
The lock is only active for the duration of the write, so it can't be used to control access to multiple variables using a single lock variable.
Accessing a shared variable would halt all threads (in our or every application?), even if they are running code unrelated to the variable being accessed.
Unless assignments are made atomic by a finer, hidden locking mechanism, read accesses would also need to lock the SV. For example, copying a PVIV into a non-shared SV would require reading the IV, PV and PV length atomically. However, this is easily fixable by extending the protection to catch all accesses, not just write accesses.
Such a mechanism wouldn't even lend itself to protecting the internal consistency of SVs if it's used internally by Perl in addition to user-level locks.
It doesn't allow the locking to span more than one SV field access, so operations which both read and write to a field (such as refcount = refcount + 1) still result in a race condition.
The lock is only active for the duration of the write, so it can't be used to control access to multiple fields (such as PV and its length). Most operations (including operations as basic as an assignment) require access to multiple fields atomically.
A few other issues I can't answer come to mind.
Would the opcode execute at a higher priviledge level? If so, problems in Perl and in XS become more dangerous and harder to debug.
Would this mechanism work on a multi-core or a multi-processor system?
When in the protection violation handler, are only perl's threads frozen, or are all threads on the system frozen?
Update: I initially stated "the mechanism would lend itself well to protecting the internal consistency of SVs if it's used internally by Perl in addition to user-level locks", but I reversed my position immediately after posting. I don't know what I was thinking.
Update: Added examples. They are hidden behind spoiler tags to avoid cluttering up the post. The examples assume both read and write accesses (as opposed to just write accesses) lock the SV (which solves problems without adding any).
In reply to Re: A faster?, safer, user transparent, shared variable "locking" mechanism.
by ikegami
in thread A faster?, safer, user transparent, shared variable "locking" mechanism.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |