On Wed, Apr 27, 2022 at 11:40 AM Henry Rich <[email protected]> wrote: > 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.
Yes, for analytic reporting, where we're doing intensive computation work on the values from those names. No, for editing contexts and algorithms implementing analogous feedback mechanisms. Generally speaking, it's on the programmer to decide what needs to be atomic. For good performance, the programmer needs to make well informed choices here. > 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. Mostly. What the programmer should want here is (shorthand): "u under locks" (in other words unlock needs to be the dual of lock, and this needs to work reliably without creating deadlocks). A problem here is that unlocking in the same order that locking occurred can (in the general case) trigger deadlock detection mechanisms. A "lock single name" mechanism, used naively, tends to create situations which are indistinguishable (inside the interpreter) from deadlock conditions. > 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. Listing does not need to be super fast, but it's needed for debugging. It should be sufficient to be able to ask the interpreter if a name is locked. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
