On Thu, Apr 14, 2022 at 2:16 PM Henry Rich <[email protected]> wrote: > About the names, I see your point, but there is a case for using . > before : and unless there is a groundswell of discontent I'm going to > leave it as is.
Well... q: u: and x: are counter examples. It was my hope to: (a) implement taylor series support as a J library, and (b) reinstate the taylor series primitives to use this library as their implementation. Having the primitives in use for something else blocks that effort. > I assume you mean how do we allow concurrent read/write to the same name > from multiple threads. 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."). It's not something we have to solve right now. I was more looking for guidelines on how the current system works. > The usual primitives are > > * readlock/writelock, where a user takes a readlock to indicate desire > to read, and a writelock to indicate desire to modify. Any number of > readlocks may be simultaneously held, but a writelock is exclusive of > all other locks. > * semaphores, where writing to a name blocks until the previous value > has been read and reading blocks until the next value has been written. > * 1-to-n semaphores, where n readers must read the value before a new > one can be written > * mutexes, which are like writelocks but yield the processor while > waiting for the lock Generally speaking, these are all built on atomic operations. And, if we have an atomic operation, we can build locking on top of it. That said, it's possible that what you have already implemented is enough here. > 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. My understanding of K is that it does not implement threads -- instead, it is optimized for having multiple K processes communicate: (a) K's standard way of representing code and data is in "serialized form" -- console output is the exact same format that another K process is prepared to parse, and (b) K is concise in its representation of other K processes. However, I believe Dyalog APL does implement threads, and that community's experience might prove relevant to us. > In the implementation, values can be modified in-place while another > thread is looking at the value. Assignments are safe: the new value > replaces the old one atomically, and tasks looking at the old value will > continue to have the old value as long as they need it. That should be good enough for my purposes. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
