dynamically changing select{} cases from another thread

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
Posts: 1
Joined: Fri Aug 16, 2019 11:02 am

dynamically changing select{} cases from another thread

Postby georgeyates » Fri Aug 16, 2019 11:05 am

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:


case <some cond>
<do something>
case <some other cond>
<do something else>


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
Posts: 31
Joined: Fri Dec 11, 2009 9:33 am

Postby MuellerNick » Fri Aug 16, 2019 12:16 pm

Are you using an interface or a chan?

User avatar
XCore Addict
Posts: 174
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Sun Aug 18, 2019 2:50 pm


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.

Who is online

Users browsing this forum: No registered users and 5 guests