[[notification]] and [[clears_notification]] only for single client usage?

[aclassifier]

Code: Select all

typedef interface a_conn_if_t {
    void  do_io_server (const unsigned value_to);
    [[notification]] slave void all_clients_seen (void);
    [[clears_notification]] {unsigned} get_result (void);
} a_conn_if_t;

The [[notification]] and [[clears_notification]] are documented in [1].

I am struggling with a system where there are (like) 8 clients and 8 servers and I try to make a system where they would all be synchronised. It's all described in a blog note [2], but at the moment this point is not clear at all.

Each client is connected to three servers (and each server to three clients) - none of the clients with each other, none of the servers with each other. It's a torus topology, with always three neighbours. The theme in the blog note is something else, but my main question here is about some conclusion I am testing:

The [[notification]] and [[clears_notification]] scheme is only thought to be used in an asynchronous scheme to protect a server from being used by more than one client at a time. It will not work for multiple clients inside a server.

If I am wrong on this then I need to debug further.

I have tried to use it for three clients, when all are "inside", all having called do_io_server then they all get a notification all_clients_seen each and all respond with get_result which clears the notification.

My code stops after some time, and I can see in the debugger that it stops on the same place. Running the same with a clean do_io_server interface works, but then they are really not "fair". One or two clients may be hot spots. That's what I tried to fix, either with a [[guarded]] (but the compiler crashes (reported to XMOS)) or with the above scheme.

The reason I thought that the scheme wasn't thought to cover my case is because if I drop [[clears_notification]] then the code runs further. Also that in [1] it says that

Once the server raises a notification, it triggers an event at the client end of the interface. However, repeatedly raising the notification has no effect until the client clears the notification. This can be done by marking one or more functions in the interface with the [[clears_notification]] attribute. The client will then clear the notification whenever it calls that function. (page 24)

which means that there is some low level state or lock that the compiler keeps track of below the hood. For one-client-in-at-a-time logic?

I see that my functionality really is that of a barrier, which I have built, but at that time I was forced to use channels. I think I now know why. That code is at [3] 209.alive.

[1] XMOS Programming Guide (as of 17Jan2018: 2015/9/21 version F, 2015/9/18 in the document), see https://www.xmos.com/published/xmos-programming-guide

[2] My XC combined combinable notes (Disclaimer, no money, ads, gifts, only fun and expenses)

[3] My XC code downloads page

[CousinItt]

You don't need to use [[notification]] and [[clears_notification]] to manage multiple clients. If only one client can access the server at a time, you can manage a mutex within the interface functions themselves.

i2c_master in lib_i2c is a good example. The server interface handlers deal with mutex assignment, but are also guarded, based on the mutex values, so the server will only respond to a client if the server is free, if it is already assigned to that client, or in the default case that there's a single client.

[aclassifier]

CousinItt, thanks for your response!

Off Topic

Searching for => in i2c_master_async.xc the only place I find it (except for a timerafter) is here:

void i2c_master_async_comb(server interface => i[n], ..)

which triggers a question: what does => in this context mean?

But then, in i2c_master_single_port.xc I find in i2c_master_single_port an unsigned locked_client = -1; which is used as a guard here:

Code: Select all

      (n == 1 || (locked_client == -1 || i == locked_client)) =>
      c[i].read(uint8_t device, uint8_t buf[m], size_t m,
              int send_stop_bit) -> i2c_res_t result:

which seems to let a client in if it's free, and then not allow any other client than the one that's in.

However, in my case I will let 3 clients in simultaneously, and those clients need to be unique, like 0,1,2 ("fair"). 0,1,1 is not allowed, meaning none of the clients (3 per server) can proceed until a server has seen all 3 clients. I have attached a PDF of a 4*4 topology (torus). A guarded single interface call would have been nice, just lock a client out once seen. But that example crashes the compiler at "..lower_combined_pars.cpp, line 183".

I have discussed this at and several solutions at [1]. The example I like the most is at [2], but it doesn't scale. It's only 2*2, but each task spawns 3 subtasks. I also made a source-comm diagram of it, also attached. I really did not anticipate not to find a combinable solution here.

My goal is to run at least 72 client and 72 servers. I've done that, but the code is not fair. Or over a thousand (it's for a fringe at a web conference IEEE-COPA 2021). (Of course this is not the kind of system the XCore was built for, but this is just for fun. I have managed more with [[combinable]], but I have found no solution that would be fair and not crash the compiler (except the 2*2 example), since my a_conn_if_t; in the first posting I have not succeeded with, and the guarded version crashes the compiler.

Maybe there is anything in lib_i2c that I still can use, but until you tell me "with a spoon" I am not able to spot it.

Øyvind

[1] https://www.teigfam.net/oyvind/home/tec ... ble-notes/ (Press "Fairness" in the TOC)