安全地允許多個客戶端共享一個資源

Question

我正在創建一個程序，需要通過不同的物理連接（串行端口，UDP）與多個設備（按10-20個設備的順序）進行通信。 這些設備僅答復我對它們的請求，並且每個設備僅在允許一個新請求之前處理一個請求。 應用程序可能每秒請求它們中的每個值更新。

到目前為止，我有一個接口IRequestReplyDevice

public interface IRequestReplyDevice
{
    T SendMessage<T>(IMessage message) where T : IMessage;
}

其中，SendMessage是阻止調用，它返回從設備接收到的響應。 在此接口的每種實現中，例如。 SerialPortDevice : IRequestReplyDevice ，我在SendMessage中有一個鎖，可以確保在收到對上一個答復的響應並將其返回給調用方之前，不發送新消息。

我想在此基礎上構建一個Web API，這可能會導致多個客戶端希望同時從同一設備請求某些內容。

這種方法是否健全或理智？ 您會采取不同的方式嗎？

Answer 1

基於以上內容，我最初的想法是刪除阻塞調用，並盡可能將請求和響應鏈與隊列分離。

流程類似於以下內容

請求-> RequestQueue-> RequestHandler-> ResponseQueue-> ResponseHandler

該建議的基本原理是，阻塞呼叫和多個用戶的固有並發性將導致很多復雜的鎖定，鎖定將具有固有的瓶頸，並且可能無法很好地擴展。

但是，該解決方案的問題在於它將涉及大量的額外工作和活動部件。 這就引出了一個真正的問題，即您實際上需要系統采取什么行為？ 設計一個要求高吞吐量（1mb / s？1gb / s？）和低延遲（100ms以下？3ms以下）的系統並發性很好的系統很快就會變得非常復雜。

如果系統可以容忍簡單的塊/鎖設計背后的延遲，吞吐量和擴展要求，則絕對不能使用它。 如果您已經在負載下測試了基於鎖的體系結構的性能，並且性能不能令人滿意，或者您有合理的預期，該系統將增長到不久的將來無法滿足要求的程度，建議看一下使用隊列。