Atomicity of handling of port pins Topic is solved

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:

Atomicity of handling of port pins

Post by aclassifier »

I have been reading [1] but I still wonder if this is "thread" safe. It compiles:

Code: Select all

static unsigned int port_value = 0;
[[combinable]]
void server_power_heat (server power_commands_heat_server_if power_commands_heat_server) {
    while (1) {
        select {
            case power_commands_heat_server.command (const power_commands_heat_t cmd): {
                port_value or_eq (1<<10);
                myport_p32 <: port_value;
            } break;
        }
    }
}

[[combinable]]
void server_power_light (server power_commands_light_server_if power_commands_light_server) {
    while (1) {
        select {
            case power_commands_light_server.command (const power_commands_light_t cmd): {
                port_value and_eq compl(1<<10);
                myport_p32 <: port_value;
            } break;
        }
    }
}
  1. Will the scheduler run either to completion?
  2. Is this any paramemeter of "combinable"-ability or placement on cores?
What I do see is that I must be fiddling with the other bits!? I asked about that at https://www.xcore.com/forum/viewtopic.php?f=44&t=5095, chapter "Not touching other pins also defined in a bigger set"

[1] https://www.xcore.com/forum/viewtopic.p ... ty&start=0 XCore Architecture Block Diagram


View Solution
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

Any case in a select statement will run to completion before the next case is executed (if there is a new event). See for example section 2.2.2 of http://xtask.org/xmos_thesis.pdf for an explanation of how a select statement is implemented.

The fact that you have two combinable functions with separate select statements does not matter, it just tells the compiler that this can be merged into one big select.

One exception I can think of is if you also are using interrupts, but interrupts are not supported by XC so you will not use them accidentally.

As long as both functions are executed on the same logical core, you should be good. I expect that the compiler will complain about resource disjointness if you run the two of them on different logical cores. I am not completely up to date though about whether it is possible to share ports between logical cores using the new pointer functionality.
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

Thanks! This helped a lot!

But if I remove [[combinable]] the compiler still won't complain!?

I'll come back with an update when I have started those tasks since for now they are only stubs, not placed or run.

Update: Without [[combinable]] the compiler complains about "violates parallel usage rules". Great! I'll come back with [[combinable]], being at the code stubs phase on this the compiler has so many user rules that I have to comply with (like "client interface cannot select on non slave function") that I need some more time. Great again! This XC language, I have a feeling I'll end up liking it even more than occam!

Update: [[combinable]] or not makes no difference. The compiler complains about violating parallel usage rules both for port_value and myport_p32:

Code: Select all

use of `usage.anon.3' violates parallel usage rules	main.xc	/_Aquarium/src	line 56	C/C++ Problem
use of `myport_p32' violates parallel usage rules	main.xc	/_Aquarium/src	line 56	C/C++ Problem
I don't know why it says usage.anon.3 instead of port_value. The errors are given at the upper parallel placement code, since that's the first place where this rule is applicable. Again, I like it very much!
Post Reply