Timing of interface related events in a select case

[sprajagopal]

Hi,
I had been using channels exclusively. I recently shifted to interfaces. The code is now more elegant.
One issue I face is the timing related to interface calls.
Say thread 1 calls interface A_interface's functions foo and other consecutively:
A_interface.foo()
A_interface.other()

A_interface is being monitored by thread 2, in the following way:

Code: Select all

while(1){
select{
#pragma ordered
case A[int i].foo():
/* code */
break;
case A[int i].other():
/* code */
break;
}
}

If I had used channels, I know for sure that the foo() call would be honoured first. The other() call wouldn't be made until foo() is done from thread 1.
In case of interfaces, how does this work? Since interface calls are nonblocking, is it possible for other() to be executed first?

[Gothmag]

As far as I know interface calls are blocking. They're just like normal function calls, but maybe this is different for non returning calls, I really havent looked that deeply into it. If you want non blocking interface I think it has to be a notification. As far as ordering I do believe you need to add [[ordered]] instead of the pragma but that too could be wrong. I haven't needed to use it and sometimes the functionality changes but documents do not.

When ordered selects have two events though they should be called appropriately since the first would be highest priority and it'd go from there. But if called from a single thread I'm notnsure it matters since I do believe they're blocking calls.

[larry]

That's right. xC interface calls become transactions on hardware channels, which are blocking. Calls will be executed consecutively in this case.

[infiniteimprobability]

One design idiom for the server side that mitigates the blocking nature of interfaces is using a guard on a select case (which can also be the default case) like this:

Code: Select all

    int do_proc_flag =0;
    while(1){
        select{
            case trigger_my_processing():
                do_proc_flag = 1; 
                break;

            do_proc_flag => default:
                /* Do processing here */
                do_proc_flag = 0; 
                break;
        }
    }

You can be in and out of the select case very quickly on the client side and this will then trigger the processing in server thread. Of course it will be non responsive until it has completed it's processing.

I've used this a few times in cases where you dedicate a thread as slave which does some DSP and you swap buffers each time you trigger it.. An practical example can be found here:

https://github.com/xmos/lib_src/blob/ma ... in.xc#L223