New 15Aug2018,updated 11Feb2019
This presentation is for the CPA 2018 conference in Dresden. It is a “fringe presentation”, meaning that it is informal and has not gone through standard peer review, ie it is my sole responsibility – even if I have signed the Author’s Declaration about it. The title is meant to be laborious to exhaust the problem I try to unravel:
Unravelling XC concepts [[combine]], [[combinable]], [[distribute]], [[distributable]] and [[distributed(..)]] plus par and on..
Press picture to run it in Apple Keynote. A PDF export for reading pages and printing is here – and with all build stages here. I also have a PowerPoint .pptx export here (I’m not certain how well it runs).
Below is the Abstract. It will appear in the conference proceedings (press picture to read PDF):
Here are some of the comments that were given during and after the presentation plus when chatting with people. I did the presentation in the Campus Bar with a very long hdmi cable to the projector. So I should have kept to the around 20 lines per slide, since my code examples became blurred. Process, task and thread are the same thing here. But hw thread is another matter:
- The transputer has so called “hardware and software equivalence”, meaning that the same software would run with the same behaviour, being placed on the same transputer, the neighbour computer of across transputers. Synchronisation, with acknowledge messages going back was also kept. However, any timing of races would differ for these cases. The question was whether the different placement of the code on the xCores would have the same property of hardware and software equivalence? My answer is that I would think so, provided the coding is thread safe, with no fiddling with pointers(?)
- The transputer had a scheduler in hw but channels etc. were handled by sw helped by channel and ALT instructions etc. For the XC “there is so much more in hw”, like there would be a limited amount of timers and chanends for this very reason. The reason (said another guy) was that the xCore did make it possible to have better control of timing and guarantees. For that reason each core could handle one hw thread (one of the full tasks, with the cnt++ allowed in my code examples)
- Therefore, when XMOS added combinable ond distributable tasks (around 2012?) it was for the user to be able to run more than one sw task per logical core. I told that this was “before my time” so I had not thought of this as solving a problem introduced by the architecture. For me it was a way to pack more than one task on a logical core, which I certainly appreciated. (Hey, “packing” – might this be the missing common denominator for combinable and distributable?Any commen term for combinable and distributable? See Any commen term for combinable and distributable? on the xCore Exchange)
- Still people believed that this was a rather elegant, and they said that being aware of the three types of tasks (everything allowed, (as always in occam since PROCs were pure sw), combinable and distributable) was really quite interesting. People saw that this gave an understanding of what it would mean to schedule and run each of these process types
- The guys were wondering whether an interface with interface calls would be “like an object-oriented class with methods”? I said “no”. The original OO-object is not “Runnable” (like a Java object may be) (which in itself doesn’t make it to a Java Thread). XC functions, once started within a par with interface or channel params, are threads. XC chan is untyped, but XC interface has RPC-like functions (Remote Procedure Call) with input and output parameters. XC tasks may be client or server by those reserved words. This lets the XC compiler watch over and protect intermediate stages in a session sequence with the [[notification]] and [[clears_notification]] decorations used on the function definitions in the interface. Therefore an XC interface and XC tasks will also help you with being deadlock free by supporting thread safe and atomic usage of a client-server role realationshop. So, “no”, XC tasks and interface would not at all be “like an object-oriented class with methods”? This also shows the major difference between an XC interface type and an xc chan.
Synchronous and asynchronous
Update 15Oct2018: I discovered that XMOS in some libraries coin
[[distributable]] tasks as synchronous and as having blocking operations, while
[[combinable]] tasks are asynchronous. Interesting! See XC is C plus X, chapter “XMOS libs: synchronous/blocking when [[distributable]] and asynchronous when [[combinable]]”. The downside of this is that a
[[distributable]] task that pathologically hangs (like looping around waiting for a bit from some input pin, without a counter or timeout) would block the calling task as well
[[distributable]] for sharing memory
[[distributable]] is nice for sharing global vairables. See Ways to share memory on XCore Exchange