On Thu, 14 Apr 2022, Henry Rich wrote:
I don't think simultaneous write access to different parts of a value is called for, though it would not be impossible (read this as "nothing is impossible if you don't have to do it yourself.").
No transactional memory, then? :)
* readlock/writelock
I don't think spinlocks are appropriate for userspace code, because of interpretive overhead.
My great hope is that someone will point to an APL/K implementation that shows the right way to do this. Otherwise we will have to design our own.
I think there is nothing to be found. The k paper indicates it uses parallelism internally, but does not expose concurrency primitives to userspace as a design choice; and afaik dyalog has 'futures' (~pyxes) and 'isolates' (~tasks/threads), but does not permit tasks to ever share access to mutable data (they are 'isolate'd).
I think your list of primitives is not a bad one, but I think it may be worth considering whether higher-level primitives are more appropriate for j. I've mentioned queues a couple times now; I think they are a good idea, and they are also a good fit for distributed which is in turn a good fit for a nominally referentially-transparent language.
Beyond that, locks at the least are probably unavoidable. Recursive/nonrecursive should be a controllable option due to single-threaded reentrancy issues. Locking should be a conjunction, not a verb.
-E ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
