Read- and write-locks as you describe are what we use for public
locales. Each lock requires a RFO cycle, plus more if the lock is
contended.
Private namespaces require no lock, since nothing can ever contend. We
would have to add something to those paths.
Those paths are carefully timed and any change that slows them down
would have to be justified.
hhr
On 1/18/2023 1:49 PM, Raul Miller wrote:
Note that, conceptually, at least, your proposed name_.. might not
need full locking of all name lookups.
Such locking is technically only needed when an execution containing
the specific name has been parsed.
So, conceptually speaking, most name lookups would only need a "read
lock" (which can be shared by many readers) except for names marked
under a parse activated "write lock" (which must be unique). Once a
name is marked with a non-zero _.. count that name lookup would need a
unique write lock before its value could be relied on, but if that's
needed for correctness, it would be a worthwhile cost.
When the parse is discarded it would need to decrement any _.. counts it had.
Note that this would mean that shadow names would need to be retained
even after a name was erased, so erase (and assignment and the copath
mechanism) would also need some additional locking logic which is
cognizant of the copath of the namespace which has those shadow names
(pushing the lock count down the path if a more global name exists,
subtracting the lock count when the shadow is no longer cast).
In principle those read locks might be negligible but that's an
uninformed judgement on my part. I don't actually know how slow they
would wind up being...
Elijah, Henry: Does this sound like a plausible mechanism to you?
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
