BehaviorSubject not eventually consistent?

[mattpodwysocki]

Copied from https://rx.codeplex.com/workitem/61

I noticed that BehaviorSubject doesn't hold a lock while it sends notifications. I assume this is to avoid some subtle deadlocks, but now there's no mechanism present to prevent notifications from being re-ordered.

I always assumed that subscribing to BehaviorSubject was eventually consistent with respect to the latest value. That the latest notification was the latest value. So...
◾Is that not the case?
◾Is that intentional?
◾What about enqueueing things to notify (while holding the lock) then draining the queue (outside the lock)?

[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.