BehaviorSubject not eventually consistent?

[dotnet]

BehaviorSubject not eventually consistent?

[mattpodwysocki]

RxJava fixed this issue with the mentioned mechanism (queue inside a lock to maintain order, have the first producer drain the concurrency queue outside the lock until it's empty). It's a potentially breaking change though, in that sending a new value may be queued instead of completing inline.

[akarnokd]

You can do this lock-free. Instead of a plain queue, use a linked-node structure with volatile next pointers. Each subscribing Observer gets a manager Object that picks the current head of the linked structure and walks the nodes until their end; doing it while in a so-called drain-mode. The role of the outer BehaviorSubject.OnNext is to add to the tail of the linked-node structure, move the head pointer one further and notify each active Observer's manager to enter their drain mode. The drawback of this is the constant allocation of nodes for each incoming value - just like the size-bound ReplaySubject does it.

[akarnokd]

BehaviorSubject uses a lock to capture a snapshot of observers. When an observer subscribes, the subscription and the last cached value is emitted under this lock, thus a concurrent OnNext has to wait for it and no reordering happens.