Spinlocks are essentially free when there is no contention. That would
be true even if they were coded in J, but I would make them a primitive,
since ultimately they need an atomic operation.
The use case where spinlocks would make sense is
* The shared data is large, possibly multiple names
* The lock control is small, maybe an atomic integer
Threads would take a readlock on the lock control when they want to
access the data. A thread wanting to modify would take a writelock.
Depending on how often the data is modified, this might be enough.
Queues look quite reasonable too, as you say.
Henry Rich
On 4/14/2022 2:53 PM, Elijah Stone wrote:
On Thu, 14 Apr 2022, Raul Miller wrote:
Well... q: u: and x: are counter examples.
u. and x. collide (x. is historical but I think x: predates its removal)
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.
There is currently no way to synchronise.
Atomic compare-and-swap (or equivalent) are technically sufficient,
but spinloops are slow--especially if implemented in j--unless you are
only doing a small amount of work in them; and present j
implementations are not very good at doing only a small amount of
work. In the case where a problem _demands_ doing a large amount of
work, you are also left high and dry. It is necessary to piggyback
atop the kernel's scheduling system to implement synchronisation
efficiently.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
