You give a good catalog of the reasons multithreading is worth doing!
Assignment is already atomic (in the upcoming beta-c where some more
bugs are fixed). You can assign and delete names at will and threads
won't crash.
BUT I am sure that more is needed. If task A wants to send info
repeatedly to task B, say in a global name, there has to be a watertight
way for B to know when the data is ready and for A to know when it is
safe to overwrite it. That's what I was talking about.
If a task always starts with all the information it needs, no further
synchronization is required.
Henry Rich
On 4/14/2022 2:31 PM, 'Pascal Jasmin' via Beta wrote:
My usual jbreak invocation (haven't tried on j904 yet) is to invoke it 2-5
times, because there is rarely an immediate response from J. I have no idea
whether the extra invocations actually help, other than bashing the command has
no competing use for my time, in those moments.
If the user issues a second break before the
ATTN has been noticed, it will force immediate termination of all tasks
with the 'break' error.
You're suggesting that a single jbreak might preserve more information to inspect. I'm
not sure if this is current single threaded behaviour, and a 2nd jbreak press, can indeed
achieve quicker break by losing the necessary coherence with the "softer" error
of a single jbreak.
As to, unrelated, your general release statement was to "work on a mutex/locking J
enhancement primitives." :
There has been a lot of recent work, by you, to make in-placed code for
efficiency. It would certainly benefit threaded code as well.
From a user perspective, if there was just an internal locking mechanism that made =: =.
"atomic" such that read/write accesses were blocked until the assignments were
complete, then there is nothing the user is forced to consider in order to safely
read/write variables. Reading threads being automatically blocked until =: completes, or
inplace + =: operation completes.
With that said, my kv implementation could be structured with internal threading benefits. A
global variable or object reference being explicity assigned to a thread (such that no copying is
needed when accessing/communicating with that variable/object, ie. thread already knows its,
potentially large, internal data, and if that global/object is y, then only the function and x
needs to be sent to the thread, provide greater system throughput, even if it means queueing
commands/read/write access to a thread. This "thread owns a global/object" functionality
would reduce the need for alternate zeromq control of "datastructures" instead of the
benefits of just t. 'myglobalvar'.
So instead of users manually locking variables, locking being automagical would
be a user benefit. One alterative interpretations of of f t. 'G' would be G =:
[x] f t. '' G. ie. an implied y from conjunction. A definition of a perfect
function is one that can be fed as (u^:) such that the result is of compatible
shape for reapplication of u, and so the result is a good candidate for
replacing the variable containing y. There are many f s, and an encouragement
to design f s such that that f t. 'G' would be useful to J programmers, and
unlike my previous suggestion, instead of allocating G to a specific thread, it
would just provide enough info to lock reads from other threads until the
operation completes.
On Thursday, April 14, 2022, 12:18:48 p.m. EDT, Henry Rich
<[email protected]> wrote:
The next beta will support jbreak in multiple threads, as follows:
Recall that running jbreak once raises the ATTN condition. This is a
gentle tap on the shoulder, asking JE to stop at the start of a new
sentence. A thread that is stopped by ATTN can be restarted reliably.
Running jbreak a second time raises the BREAK condition. This poleaxes
JE into immediate insensibility, possibly in the middle of a sentence,
and you are on your own to decide whether continuation is feasible.
When debug suspension is disabled, a single jbreak will be detected by
the first task that starts a sentence. That task will fail with an
'attention interrupt' error. The system will then automatically
simulate a second jbreak to force quick termination of all other tasks
with the 'break' error. If the user issues a second break before the
ATTN has been noticed, it will force immediate termination of all tasks
with the 'break' error.
When debug suspension is enabled, a single jbreak will be noticed by all
tasks when they start a sentence or when they wait for a pyx after
another task has noticed the break. After all tasks have noticed the
break, the system enters debug suspension. The first thread that
noticed the break will be the debug thread and the others will be
dormant until execution is resumed. If the user issues a second break
before the ATTN has been noticed, all tasks will interrupt their
sentences as soon as possible to enter debug suspension with the 'break'
error. You are on your own to decide whether continuation is feasible.
There is no automatic detection of deadlock. double-jbreak is the only
way out of deadlock/livelock.
Henry Rich
--
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
