On Wed, Apr 27, 2022 at 2:47 PM Elijah Stone <[email protected]> wrote: > 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.
That's an interesting question. > 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. Henry is already giving us semaphores. That said, an atomic operation (such as would be provided here) would allow the programmer sufficient control to build other mechanisms. What I think we want, though, is something which minimizes unnecessary verbiage -- stuff like "this operation is really only useful in this phrase" (so why wasn't that phrase introduced as the primitive?). > 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?) Hmm... I guess I was thinking about recursive cases there. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
