Disruptor Next/Publish 메소드에 대한 액세스를 동기화해야합니까?

Question

아래 코드는 방해 요소가있는 사람들에게 충분하기 때문에 전체 목록을 제공하지 않습니다. Next 및 Publish 메서드를 호출하면 스레드로부터 안전할까요? 아래의 예들 사이에 올바른 것이 무엇일까? Attach은 다른 스레드에서 동시에 호출 할 수 있습니다. 그리고 나는 여러 소비자가있다.

실시 예 1. 모든 것을 잠그십시오 :

private object attachLock = new object(); 

    // can be called from parallel threads 
    public void Attach(OrdersExecutor oe) 
    { 
     lock (attachLock) 
     { 
      long sequenceNo = ringBuffer.Next(); 
      ringBuffer[sequenceNo].Value = oe; 
      ringBuffer.Publish(sequenceNo); 
     } 
    } 

예 2. 다음 잠금 :

private object attachLock = new object(); 

    // can be called from parallel threads 
    public void Attach(OrdersExecutor oe) 
    { 
     long sequenceNo; 
     lock (attachLock) 
     { 
      sequenceNo = ringBuffer.Next(); 
     } 
     ringBuffer[sequenceNo].Value = oe; 
     ringBuffer.Publish(sequenceNo); 
    } 

예 3. 없음 잠금

후드에서

private object attachLock = new object(); 

    // can be called from parallel threads 
    public void Attach(OrdersExecutor oe) 
    { 
     long sequenceNo = ringBuffer.Next(); 
     ringBuffer[sequenceNo].Value = oe; 
     ringBuffer.Publish(sequenceNo); 
    } 

Answer 1

나는 disruptor-net의 저자입니다.

disruptor는 동시 수집이므로 한 번 제대로 구성하면 잠금을 적용 할 필요가 없습니다. 여러 개의 생성자가 있으므로 예제 3을 사용하여 링 버퍼에 게시하므로 RingBuffer를 MultiThreadedClaimStrategy로 초기화해야합니다.

그런데, 생산 코드에서 disruptor-net의 사용을 권장하지 않으며, 여유 시간에 얼마 전 포팅하고 프로덕션 코드에서 사용하지 않았으므로 추가 테스트가 필요합니다.

.NET 동시 대기열이 Java 대기열보다 훨씬 빠르기 때문에 ConcurrencyQueue를 Disrutpor 또는 Disruptor에 매우 가까운 의미를 제공하는 BlockingCollection 대신 사용할 것을 제안합니다.

Answer 2

는 Next() 및 Publish()의 구현은 Interlocked 정적 클래스를 기반으로하지 않습니다. 그래서 코드는 으로 설계되어 스레드 안전성을 보장합니다. 쓰래드 안전하고 지진처럼 보입니다. 하지만 스레드 안전합니까? 나는 모른다.

이 프로젝트는 매우 활발한 것처럼 보이지 않으며 자바 API에 뒤처져 있지 않습니다. 일부 테스트는 실패하고 (Mono) 일부 기능은 전혀 테스트되지 않습니다 (WorkerPool). 조심해서 사용하십시오.

나는 그를 초청 한 저자에게 편지를 보내 왔으며, 그의 설명을 기다리 자.