1. Wouldn't it be better, in most cases, to copy the names in v
atomically and then run u on the copy? That would keep the names tied
up for much less time.
2. Wouldn't a simple readlock/writelock on a name give the same result?
It would be easier to implement. A routine that wants to use a shared
name would establish a readlock on it before copying or using the value;
a routine that wants to write to the name would establish a writelock.
If there are multiple names, all users should agree on an order and lock
the same name.
I am thinking that would give the same benefits as your suggestion, more
simply.
Read/write locks can be implemented with very little overhead. I would
say that if you want to be able to list the locks you would need to
implement a verb to add that layer of functionality.
Henry Rich
On 4/27/2022 11:20 AM, Raul Miller wrote:
On Wed, Apr 27, 2022 at 10:47 AM Henry Rich <[email protected]> wrote:
3. beta-c has new T.-verbs that allow you to create semaphores. This
would do what you are describing. More verbs will certainly be needed
(mutexes, for example) and we welcome suggestions.
What I think I would want is a conjunction which gives me atomic
execution of u for the list of names in v (which might include mapped
files).
I would expect this mechanism to wait if any of the names in v were
"in use" by another "atomic execution" where they had been listed in
the same order as in v.
I would expect this mechanism to throw an error if I attempted to use
it while names in v were "in use" by another "atomic execution" and
had been listed in a different order from their order in v. (I think
this is necessary for deadlock avoidance.)
I would expect names to be unlocked in reverse order from the order
they were locked. (I think this is also necessary for deadlock
avoidance, and fits nested (stack based) executions.)
The atomic mechanism here might wait in a queue which gets rerun after
names get unlocked. (It might wait for a while and then error out
because of intervening "lock changes".)
This would effectively be a write lock for those names. If I just want
a consistent copy of those values, I can atomically pull their values
into an array (or a fresh locale) and then forget about the names. But
I guess that this means that while the atomic mechanism was running, I
would want to lock out assignments to those names even from code which
was not running under this atomic mechanism.
For debugging purposes, I would also want to be able to list current
and pending locks.
Thanks,
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
