Using [[distributable]] task in a [[combine]] par

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Using [[distributable]] task in a [[combine]] par

Post by aclassifier »

if a task is [[distributable]] then starting it within a [[combine]] par is legal.

This seems understandable, as a task first needs to be [[combinable]] before it void of timerafter and pinsnseq etc to become [[distributable]] as responding only on interface calls.

Does this mean that the [[distributable]] is then only (by the compiler and mapper(?)) treated as a [[combinable]]?


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Gothmag
XCore Addict
Posts: 129
Joined: Wed May 11, 2016 3:50 pm

Post by Gothmag »

Semantically it's unplaced I think. More like a global resource.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

So you think the mapper then can treat that [[distributable]] as [[distributable]] or [[combinable]]? I guess in any case that's only an option for the mapper, being the one or the other doesn't mean that the mapper could treat them as none?

But this is only guessing. Anybody who knows?
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Gothmag
XCore Addict
Posts: 129
Joined: Wed May 11, 2016 3:50 pm

Post by Gothmag »

No, it's not actually combinable at all. It doesn't require its own cycles. Basically calling a function where the calling thread uses its cycles to run the code. I think the combinable requirement comes from the fact that all the code a thread runs when using distributable calls is not placed there. So in effect it is combined but only in a functional sense not a real one. It doesn't require multiple instances of the code, or duplicated "local" data. The strict nature of Xc likely requires the distinctions. The case in which that would be wrong is in a case where only a single thread is calling, that may actually simplify by combining but I haven't looked at binary output for a case like that. Maybe somebody from XMOS could chime in but they usually respond to issue topics more than theory.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

I guess this is the idea here, that it has to have the properties of a combinable but then not use timerafter or pinsneq etc, (to respond to interface calls only) so that the whole context is reached from the calling task that just runs its own cycles? Then, from [1]
This implementation requires the core of the client task to have direct access to the state of the distributed task so only works when both are on the same tile. If the tasks are connected across tiles then the distributed task will act as a normal task (though it is still a combinable function so could share a core with other tasks).

If a distributed task is connected to several tasks, they cannot safely change its state concurrently. In this case the compiler implicitly uses a lock to protect the state of the task.
Off Topic
This is so advanced that it’s almost a wonder that it works! It so beyond what the competitors do with realtime kernels and ANSI C. I just felt a need for saying it.
Of course, there has to be a strict language underneath.
[1] XMOS Programming Guide
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

But then Gothmag, my initial question, how is a [[distributable]] task within a [[combine]] par treated? Like a [[distributable]], a [[combinable]] or??

Did your first answer respond to that question, or generally more what [[distributable]] is?
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Post Reply