Page 1 of 1

dynamically changing select{} cases from another thread

Posted: Fri Aug 16, 2019 11:05 am
by georgeyates
I was wondering if it is possible to change case conditions dynamically in one thread from another thread?

for example:
one thread would look something like that:

while(1){

select{
case <some cond>
<do something>
break;
case <some other cond>
<do something else>
break;
...
}

}

so i was wondering if it is possible to have another thread change the case conditions while the select block in the first thread waits on some set of initial conditions?
I.e can i somehow manage the case conditions that one thread waits for from another thread?
I need this because i need the system to react very accurately to the constantly changing stimuli, and if i introduce some case managing code to the same thread that waits on the stimuli, it may delay the reaction to the stimuli (say when condition fires during the time management code is executing) and will make it not perfectly real-time as required.

if anyone has some other suggestions on how to implement this, i'd appreciate hearing them

Re: dynamically changing select{} cases from another thread

Posted: Fri Aug 16, 2019 12:16 pm
by MuellerNick
Are you using an interface or a chan?

Nick

Re: dynamically changing select{} cases from another thread

Posted: Sun Aug 18, 2019 2:50 pm
by CousinItt
Hi,

you can use guard conditions on events in select statements. The guard conditions are expressions that evaluate to a true or false state to enable or disable each event. See the chapter on event handling in the XMOS programming guide for more information.

These guards are executed in software, so the more complex they are, the slower they will be. A select statement responding to messages from another task can modify variables which form part of the guard expressions used in the same select statement. The response to an event in a select statement is delayed while it is handling another event. That's the nature of the beast. If guards and the associated code aren't quick enough for you, there may be alternatives such as clever port programming or sharing the work between more than one task, but try guards first. As the saying goes, premature optimisation is the root of all evil.