Here is some odd behaviour I encountered while trying to induce a race condition:

   {{0 T.''}} :: ] ^:_''
14
   t=: 1e9$0
   f=. {{''[echo 7!:2't=: >:t'}}t.''
   ''[ >f"0]15$0
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
8589935584
896
8589935584
8589935584

   ''[ >f"0]15$0
896
zsh: killed     ../jlibrary/bin/jconsole

1. If the second invocation triggers the oom killer, why does not the
first?  Leak?

2. Why is it always the third-to-last result printed by the first
invocation which was in-place?

3. Why only 15 threads?

Additionally:

   timex'a=. f"0]15$0'
[...]
6.05598
[...]

t. is supposed to be non-blocking, but here it's blocking for 6 seconds.

 -E

On Sat, 9 Apr 2022, Henry Rich 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

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to