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

[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]]?

[Gothmag]

Semantically it's unplaced I think. More like a global resource.

[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?

[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.

[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

[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?