跳到主要内容

上下文线程模型

您用于 IPC 的线程模型取决于上下文中是否使用了 TCP、共享内存或两者兼有的传输类型。

TCP传输的线程模型​

当 IPC 会话使用 TCP 通信时，正常的上下文线程被用于消息接收处理功能以及将接收到的消息分派到消息接收回调函数。

这个上下文线程用于所有 TCP 通信的接收处理，无论连接是用于 IPC 通信还是与事件代理通信。

上下文线程的首选模型是应用程序请求 API 在内部创建并控制上下文线程。

或者，C 应用程序可以创建上下文线程，在这种情况下，应用程序上下文线程必须循环调用 solClient_context_processEvents(opaqueContext_p)。您可以通过上下文属性 SOLCLIENT_CONTEXT_PROP_CREATE_THREAD 设置 C API 或应用程序是否创建和控制上下文线程。

共享内存传输的线程模型​

当上下文内有一个或多个共享内存通道处于活动状态时，API 会自动创建一个内部共享内存上下文线程，用于接收和分派来自共享内存通道的消息。除了正常的 TCP 上下文线程外，还会运行这个线程。

需要两个上下文线程，因为共享内存通信不涉及像 TCP 通信那样的套接字或文件描述符，正常的 TCP 上下文线程（等待一组套接字）不能用于等待一个或多个共享内存通道的流量。

自旋和阻塞共享内存线程​

您可以将共享内存上下文线程配置为硬自旋，以实现极低延迟的接收处理，或者配置为阻塞以在等待传入消息时节省 CPU 资源。您也可以配置这两种行为的组合。

当配置为始终自旋时，共享内存线程会持续轮询它正在处理的所有共享内存通道，以查找新的传入消息。使用自旋避免了操作系统调用，避免了阻塞等待传入消息时的调度开销和延迟。它提供了尽可能低的接收延迟，但这也要求应用程序为传入消息处理专门分配一个 CPU 核心。

当配置为阻塞时，内部共享内存上下文线程会在操作系统同步调用上阻塞，等待传入消息到达正在处理的共享内存通道之一。

另一个选项是共享内存上下文线程在等待新的传入消息时自旋一定次数，如果没有消息到达，则进入操作系统进行阻塞。应用程序需要调整在阻塞之前自旋的次数。这允许在消息持续到达时进行低延迟的接收处理，但当传入消息流量减少时，线程也可以回落到阻塞行为。

当两个应用程序通过共享内存通道通信时，每个应用程序独立决定是阻塞还是自旋以从该通道接收消息。

混合传输模式​

在单个上下文中同时使用 TCP 和共享内存传输时，上下文线程和共享内存线程可以将接收到的消息分派给应用程序。

当上下文中仅使用单一会话时，API 只允许一个线程一次向应用程序分派消息。这保护了应用程序，使其消息接收逻辑无需是可重入的。因此，TCP 传输和共享内存传输不能同时分派消息。然而，一个会话的共享内存线程可以为一个会话分派消息，而另一个会话正在处理来自上下文线程分派的 TCP 会话的消息。

如果应用程序使用 API 提供的计时器服务，超时事件仅从上下文线程分派，而不是从内部共享内存上下文线程分派。会话事件分派如下：

  • 如果会话仅使用 TCP 传输，则会话事件从上下文线程分派。
  • 如果会话仅使用 SHM 传输，则会话事件从共享内存线程分派。
  • 如果会话使用混合 TCP/SHM 传输，则会话事件可能从上下文线程和共享内存线程分派。