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

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 309
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

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

Postby aclassifier » Fri Jul 27, 2018 5:19 pm

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]]?
Gothmag
Experienced Member
Posts: 120
Joined: Wed May 11, 2016 3:50 pm

Postby Gothmag » Sat Jul 28, 2018 10:28 pm

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

Postby aclassifier » Sun Jul 29, 2018 10:35 am

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?
Gothmag
Experienced Member
Posts: 120
Joined: Wed May 11, 2016 3:50 pm

Postby Gothmag » Sun Jul 29, 2018 5:37 pm

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: 309
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Sun Jul 29, 2018 10:01 pm

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
User avatar
aclassifier
Respected Member
Posts: 309
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Mon Jul 30, 2018 8:58 am

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?

Who is online

Users browsing this forum: No registered users and 26 guests