| All threads within a process can access channels and channel sets. The semantics of that access is blocking. It means, that when a requested operation cannot be completed, the thread which issued that operation will be blocked. It will be made ready again, when that operation has been already completed or it can proceed. This is in contrast to non-blocking or asynchronous operations. |
| Since internally TCE uses those non-blocking calls, the performance of the thread-based communication should be slightly worse than using non-blocking calls. This is caused by the context switching costs, which have to be added to each non-blocking invocation which results in blocking a thread. |
| In majority of cases, however, this disadvantage is greatly outweighed by the clean communication semantics and a better overleap between communication and computation (greater concurrency). This approach is particularly well suited for taking advantage of dedicated communication co-processors, or more than one CPU per node. |
