Question about blocking in interface transactions
-
gerrykurz
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
Question about blocking in interface transactions
Is a client interface "initiation" of a transaction blocked until the server select case "accepts" or processes the transaction?So in a server dealing with many client transactions, any individual client transaction would have to wait until the server was able to deal with the transaction?Follow up question: When exactly is the client thread released from the "block"? Is it when the server select case reaches the break statement? Or sooner?
-
myndideal
- Active Member
- Posts: 59
- Joined: Thu May 05, 2011 10:00 pm
- Location: Budapest
yes, yes.
The xmos programming guide have a paragraph for the parallel tasks and its syncronizations / communications. https://www.xmos.com/support/tools/prog ... 53&page=23
I guess there is a transactioned communication method for channels. (but it means only we can organise multiple chan operation into one packet, the other side is triggered when all of the bytes are sent. And I guess , it is still synchronous only the packet length is handled somehow.) , This one is discussed here: https://www.xmos.com/published/how-use- ... r-channels and here: https://www.xmos.com/published/xc-concurrency It uses slave & master appellation. With this syntax multiple chan operation could build a transaction, therefore other side could wait till the proper moment, when all of the packet bytes are "sent" from other thread. I cited this here only becase this is something like a fifo, but I think this is implemented by compiler not realy in an assyncronous way. I guess there is not possible to send multiple packets while it is handled, just one at a time.
The only asynconous message (as far as I know) is the "notification", which is only usable for reverse direction to make a sign, if other task was changed its state already or not... It is implemented as send a message only at the first change/call , but any other call will be ignored while the notification state is active. There is a separate possibility to clear the notification state with one of the other specified interface function, where it is prefixed. (see docs)
So, as far as I understand to build an async communication in a multithreaded enviroment, without blocking on every transaction (or loosing datas), we have to have a fifo between the two threads. Otherwise, if we have no fifos there, one of the threads will wait to the another at least in one of the stage of the communication. Perhaps it is happened when the other side is busy with the previous message, or perhaps when theres no new message (depending on implementation). One of the good decision can be , if we can deal with the right ornganisation of the server and client side. Let we say, one of the two threads may wait for the another in a planned manner. In this case we don't need a fifo realy.
The other design concept could be to minimise the worker thread runing time, to keep a reasonable/acceptable low latency time. Furthermore, I think it is possible to design systems which able to handle multiple transactions in same time, but on multiple worker threads. And I seen a concept in lib_sdram, which use a command pool, to let the other side to prepare the next command while server still working on the previous one.
If you have a service with multiple clients, only one clients is handled at a time in a basic implementation. I can imagine if we have a par{} statement block somewhere in the server main loop, but still there's a similar theoretical problem bw its worker threads. (paralel usage rule)
The xmos programming guide have a paragraph for the parallel tasks and its syncronizations / communications. https://www.xmos.com/support/tools/prog ... 53&page=23
I guess there is a transactioned communication method for channels. (but it means only we can organise multiple chan operation into one packet, the other side is triggered when all of the bytes are sent. And I guess , it is still synchronous only the packet length is handled somehow.) , This one is discussed here: https://www.xmos.com/published/how-use- ... r-channels and here: https://www.xmos.com/published/xc-concurrency It uses slave & master appellation. With this syntax multiple chan operation could build a transaction, therefore other side could wait till the proper moment, when all of the packet bytes are "sent" from other thread. I cited this here only becase this is something like a fifo, but I think this is implemented by compiler not realy in an assyncronous way. I guess there is not possible to send multiple packets while it is handled, just one at a time.
The only asynconous message (as far as I know) is the "notification", which is only usable for reverse direction to make a sign, if other task was changed its state already or not... It is implemented as send a message only at the first change/call , but any other call will be ignored while the notification state is active. There is a separate possibility to clear the notification state with one of the other specified interface function, where it is prefixed. (see docs)
So, as far as I understand to build an async communication in a multithreaded enviroment, without blocking on every transaction (or loosing datas), we have to have a fifo between the two threads. Otherwise, if we have no fifos there, one of the threads will wait to the another at least in one of the stage of the communication. Perhaps it is happened when the other side is busy with the previous message, or perhaps when theres no new message (depending on implementation). One of the good decision can be , if we can deal with the right ornganisation of the server and client side. Let we say, one of the two threads may wait for the another in a planned manner. In this case we don't need a fifo realy.
The other design concept could be to minimise the worker thread runing time, to keep a reasonable/acceptable low latency time. Furthermore, I think it is possible to design systems which able to handle multiple transactions in same time, but on multiple worker threads. And I seen a concept in lib_sdram, which use a command pool, to let the other side to prepare the next command while server still working on the previous one.
If you have a service with multiple clients, only one clients is handled at a time in a basic implementation. I can imagine if we have a par{} statement block somewhere in the server main loop, but still there's a similar theoretical problem bw its worker threads. (paralel usage rule)