Thread Switching

[paulmansour]

I remember seeing written somewhere that the interpreter will not switch threads between diamonds on a single line. I cannot find that now. I assume that I remember that incorrectly,
as some basic tests indicate that the interpreter will indeed switch threads at diamonds.

I also remember hearing from Dyalog via email or reading that the interpreter will not switch threads between the lines of a dfn. I can't find this explicitly written anywhere either.

The documentation does state that the interpreter will switch threads on entry to a dfn, and discusses dfns separately from tradfns. This seems to imply that dfns are treated differently than trad fns, and that unlike trad fns, the interpreter will not switch threads between the lines of the function. However, some basic tests also show that thread switching will occur between the lines of any function, trad or dfn.

So on both accounts, I appear to have had a completely wrong view of how things worked.

Am I right now?

[StefanoLanzavecchia]

> Am I right now?

I certainly hope not :)
The fact that the interpreter will consider a single atomic unit in a trad fn is fundamental to the way some of our most critical code is written. Careful though: function calls are still considered switching points, so the functions and operators used on the monolith must all be primitive.

We don't use much if at all the fact that there's no thread switch between the lines of a dfn but, once again, only if the functions and operators used are primitive. As soon as you call anything that was defined, the thread might (and will...) switch.

[paulmansour]

Thanks Stefano,

You probably know this already: it appears output to the session can allow thread switching*,
so using that technique (not a good technique anyway) to observe the order of execution of fns/lines is... accurate but totally not what you want as the test changes the behavior. When I changed my test functions to accumulate the exact same info (fn name and line number) in a global variable, the correct behavior is observed: No thread switching between the lines of a dfn and no thread switching on diamonds.

Whew!

I don't think this factoid is mentioned in the docs.

[StefanoLanzavecchia]

Whew, indeed! At this point I try and remember to treat the session as a strange beast. Apart from good old []FHOLD, sitting in the session seems to trigger all sort of event dequeuing which makes the analysis of certain behaviours in the tracer impossible. Unfortunate, but most likely justified by the fact that it makes the debugging of a completely different class of behaviours possible so...

[paulmansour]

I was very aware that "sitting in the session" changes a lot, and that tracing line by line, can be very different than letting the function run in certain circumstances (like when ⎕DQ and ⎕NQ are involved). What surprises me is that merely doing in trad or dfn:

      ⎕←'hello world'

or in a trad fn:

      'hello world'

will trigger thread switching. It really never would have occurred to me. So if one were to leave an apparently innocuous line of code in....

(I'm not sure this would be a problem in the runtime interpreter, which is probably the only
place it would really matter. Hopefully the runtime short circuits attempts at session output very early on. I may test that...)

As one of the Dyalog greats so understatedly said:

Programming with threads requires care.

[Morten|Dyalog]

Page 193 of The Dyalog Programming Reference Guide lists the points at which the interpreter may switch between running threads. We believe this list is accurate. However, the meaning of the term "defined function or operator" has evolved over time. The first bullet point should refer to "traditional" functions or operators only (tradfns and tradops), and we'll be updating this in the next version of the documentation.

The current text reads:

1. Between any two lines of a defined function or operator
2. On entry to a dfn or dop.
3. While waiting for a ⎕DL to complete.
4. While waiting for a ⎕FHOLD to complete.
5. While awaiting input from: ⎕DQ ⎕SR ⎕ED
6. The session prompt or ⎕: or ⍞.
7. While awaiting the completion of an external operation:
   
   • A call on an external (AP) function.
   • A call on a ⎕NA (DLL) function
   • A call on an OLE function.
   • A call on a .NET function.

The first two bullet points will be reworded along the lines of:

1. Between any two lines of a tradfn or tradop.
2. On entry into - but not between the lines of - a dfn or dop.

We will also add the following warning:

Note that additional thread switching may occur during development and debugging:

1. When stepping through ANY code (including dfns) using the tracer, the system will unlock the keyboard and dequeue events. This will allow thread switching, and potentially also invoke callback functions if there are events on the queue.
2. If you have enabled ]boxing or other output formatting features, any output to the session may lead to function calls, also enabling thread switching

[paulmansour]

If you have enabled ]boxing or other output formatting features, any output to the session may lead to function calls, also enabling thread switching

Doh! Now that makes a lot more sense than simply assignment to ⎕. And indeed I had boxing on, though all my output was simple so it was not readily apparent.

Thanks Morten.