On Wed, 27 Apr 2022, Raul Miller wrote:
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.
1. should the lock be recursive or no? Recursive locks are more convenient in
some situations, but non-recursive ones are needed to catch reentrancy issues,
so I think it is a question that needs to be answered by the user. If a lock
is a separate object which needs to be created explicitly, this can be
specified at creation time. If a lock is implicit, over a set of names, then
an error case is created: when a given name is locked once recursively and
once non-recursively.
2. this mechanism sounds a bit like transactional memory. I think
transactional memory is a good idea. It also sounds like java's monitors.
3. I think explicit lock and unlock operations should also be provided,
alongside any higher-level synchronisation mechanism. They should not be a
primary mechanism--they should be cumbersome to use, and their use should be
discouraged--but they will be necessary in some cases, and in particular when
debugging.
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.)
I do not think there would be any issues with deadlocks, as long as the locks
are all acquired atomically. The releasing can then happen in any order.
(Perhaps acquiring locks sequentially is desirable to improve fairness?)
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
