I have a lockup situation where client core is performing:
outct(server_channel,XS1_CT_END)
while the server core is:
outct(client_channel,XS1_CT_END)
So they are locked up trying to communicate with each other. But, I thought control communications had a buffer and this was not supposed to happen, unless the buffers are full.
These channels link cores on the same tile, so they may not be buffered.
So are these channels buffered? How can I tell if the buffer is full?
Classic channel lockup, again.
-
- Experienced Member
- Posts: 94
- Joined: Sun Feb 10, 2013 4:47 am
-
Verified
- Respected Member
- Posts: 347
- Joined: Wed Jan 27, 2016 5:21 pm
Hi babazaroni,
You name them 'server' and 'client' channels; I presume these are two chanends of one chan?
ie,
In itself these two outct statements should not lock; there is a buffer (two words deep) that will happily keep them.
However, given that you have not consumed those two control-tokens, i.e., there are no matching or it may well lock up when it tries to clean up the channel itself in main. Or, it could lock up if there are another eight outct statements in front of them.
There is no test for buffer fullness - buffer fullness depends on the network arrangement and everything else, but your code can safely assume that it can hold an empty message, or a one-word message including the END control token. That way you can design high level protocols (such as implemented by <: and :>) that can never lock up the network.
You name them 'server' and 'client' channels; I presume these are two chanends of one chan?
ie,
Code: Select all
void f(chanend sc) {
outct(sc, 1);
}
void g(chanend sc) {
outct(sc, 1);
}
main() {
chan c;
par {
f(c);
g(c);
}
}
However, given that you have not consumed those two control-tokens, i.e., there are no matching
Code: Select all
chkct(sc, 1)
Code: Select all
int y = inct(sc)
There is no test for buffer fullness - buffer fullness depends on the network arrangement and everything else, but your code can safely assume that it can hold an empty message, or a one-word message including the END control token. That way you can design high level protocols (such as implemented by <: and :>) that can never lock up the network.