'Snapshot' is not possible unless your state is a single noun, and in
that case mystate =. globalstate suffices. If there are multiple nouns
there is no way to guarantee that the values are valid from the same
instant. Some higher-level primitives will be needed for this. We can
try to design them here.
You make a good point about thread termination's not necessarily being
an error, but as Raul observed, what is needed is shutdown, not
termination. The new JE has a mechanism for causing all threads to
pause, used to enter debug suspension and to perform very rare internal
housekeeping actions. I had been thinking that shutting down a thread
would be done by the user during debug suspension, but there is no
reason not to automate it as a T. function.
Henry Rich
On 4/10/2022 9:47 AM, 'Pascal Jasmin' via Beta wrote:
Some of my naive observations,
I like the design of "if out of threads, run on main thread". If you run out of
execution units, then the likely higher performance is to run on main instead of queueing/switching
between "too many threads". This does not actually guarantee that setting T. to cores -1
produces predictable performance because computer can be busy including other J environments that
also set T. to cores -1 under a presumption of being the only application running.
An implication of this model is that a thread is only running one pyx at a
time, and deleting a pyx should include the safe termination of that thread. A
command to at least delete all idle threads should be simple enough (main goal
is to avoid restarting J).
A different multiprocessing model is one permitted by zeromq. A dbms system
running on another process maintains its state and responds to
insert/set/delete/queries in some usable/rational sequence, where state means
that queries are already a function of time.
The t. model is completely unsuited to thread state. It may be possible to do (". t. '') 'myglobal =:
f worldstatedata', but you never should. Instead something like myglobal =: > f t. '' worldstatedata
is still a "semi-functional" approach where worldstatedata is snapshotted at time of call, a
functional result is returned, and then a "transactional/acid" update is made. No thread
complexity/management/races/surprises involved because the result of f worldsnapshot is functional (same
input = same output).
Killing a pyx is important if only to stop infinite loops/non termination, but also in distributed search, when some other thread has found
"the solution". Even if a user makes the discouraged practice of assigning a global inside a thread, perhaps just like
jbreak.bat, killing a thread/process only responds at some memory coherently possible point. Killing a pyx before finished, will either
result in no change to the global if it were the last action/update in the non-terminating "command", or if it was a "state
toggle" (perhaps thread locking/access management) repeatedly called by the function, then the thread was already unpredictable as to
the state, and like objects/classes, code needs a "reset toggle states" function in case of errors that cause the normal
"resets" not to execute. Killing a thread is an "ordinary error condition" that state dependence must be prepared for.
An interesting way to have t. manage state like a zeromq "service" would be to use the '' n
parameter for managing names/state in threads. So, if 0 T. 'myname1 myname2' is called, then that whenever
those names are used as arguments to functions, the function would be applied in that thread, and that thread
"owns the data", and access to "that data" would automatically even without t. call, run
in that thread.
On Sunday, April 10, 2022, 07:50:57 a.m. EDT, Henry Rich <[email protected]>
wrote:
Killing a thread is going to be a problem. What do you do with the
values the thread was using? They will never be freed. You can't just
free all the memory the thread allocated, because some of it may be
values now being used by other threads.
My thought was that you would have to interrupt the system and use the
debugger to force an error in the thread. That would be as close as
possible to killing it.
Henry Rich
On 4/9/2022 6:52 PM, 'Pascal Jasmin' via Beta wrote:
There should probably be a T. command to delete all threads (to reset total allocations
without restarting J), and to "kill a pyx and stop a thread running that pyx"
On Saturday, April 9, 2022, 06:22:03 p.m. EDT, Henry Rich
<[email protected]> wrote:
Threads can be created with options: core placement etc. The '' is for
future expansion
Likewise, threads can execute with options; for example, maybe the
master thread should be reserved to distribute work to the others.
How many cores you use is up to you. (I couldn't find an OS-independent
way to decide). JE generally does few data-dependent branches, and I
expect it would not be a good idea to use two hyperthreads in one core;
but you'll have to make that decision.
Henry Rich
On 4/9/2022 5:38 PM, 'Pascal Jasmin' via Beta wrote:
If I have a ryzen processor with 6 cores, 12 (intel term hypervisor) execution units
should I run 0 T. '' 10-11 times to "give JE" up to that many threads? a way
to shorthand that repetition:
taskS =. 3 : '0 T. '''' '^:
10 taskS ''
assumptions:
1 T. '' returns the last task id created.
2 T. '' returns a list of all task ids
3 T. '' returns 0
4 T. '' returns empty/i.0
is there a future expectation to use n in t. or T. for other than '' ? What
might that be?
t =: t.'' NB. must have convenience, if '' is constant.
a =. i.4 10000000
timex '+/&:> +/"1 a'
0.0208033
timex ' +/t "1 a' NB. should just be overhead of sending 40m integers accross
4 tasks
0.0768311
timex '+/&:> +/t "1 a' NB. includes waiting for results for final sum
0.0935162
I think these are good results. For an unsuitable threaded operation. It
scales by datavolume. 5gb/sec. The gathering is quick.
On Saturday, April 9, 2022, 03:04:28 p.m. EDT, Henry Rich
<[email protected]> wrote:
The big news in J904 is multithreading. J verbs can now be run in
different cores, sharing the J global namespaces.
[A version of J with limited support for multithreading was revealed
last year by John Ference of Monument AI. John's work was an important
proof of concept, but the J904 version is an independent development
using pthreads instead of OpenMP. John has agreed with Jsoftware to
give Jsoftware access to the code and testcases used in his work. We
have not used the code.]
Two primitives support multithreading:
(0 T. '') creates a thread on a new core. A thread running a verb is
called a /task/. Even if you don't plan to create tasks, you should
create threads to allow JE to use them for its own purposes.
([x] u t. '' y) executes ([x] <@:u y) as a task to produce a boxed
result. The thread that executed t. continues to run. But the result
is a special kind of box called a /pyx/.
['pyx' is Greek for box, and has been brought into English on occasion
when a word has been needed for a special box. The most recent such
borrowing until now is for the box used by the Royal Mint to hold coins
for assay.]
A pyx looks on the outside like any other box. You can pass it as an
argument. But as soon as you look inside it, your thread is blocked
until the task producing the pyx's value has completed. Then you see the
value, and your thread continues.
Tasks share the global namespaces and thus can freely read, write, stomp
on, and delete names visible to other tasks.
We encourage you to experiment with threads and tasks. We are sure that
a layer of synchronizing primitives - semaphores, locks, and mutexes -
will be needed, but we would like to get practical experience with tasks
before we implement them. Suggestions welcome.
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
