-
Notifications
You must be signed in to change notification settings - Fork 7.6k
BehaviorSubject Race Condition #658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
There are a few missing suggestions that I didn't have in my PR which also involves BehaviorSubject. I'll take a look at this as well. Edit: Yes, this can happen. If an observer subscribes, it immediately gets the current value, then it is eventually added to the state object via Edit 2: How to avoid it:
I thought about the queue/drain suggestion in the article, but I can't see it solving the value skip problem; (it surely acts against reordering if there happen to be concurrent onNext calls - but we don't allow / ignore those by contract). |
The queue/drain approach can be adapted to also ensure you don't miss notifications. All you have to do is queue the subscription as well. (Queue/drain is a fully general synchronization mechanism akin to using an actor.) Note that if you do this the initial value may not arrive immediately if the behavior subject is being touched on another thread, but it can be fixed by introducing a second queue specific to the subscription that was initialized with the latest value while atomically subscribing. So a no-deadlock no-reorder no-thread-hopping-for-initial-value subscription would look like:
I think that's right... just off the top of my head, though. |
If you're willing to allow the initial value to thread-hop, it's a lot simpler of course:
(assuming you're using the queue as your only synchronization mechanism. If you're also using locks, you probably need to lock around the enqueues) edit fixed enqueueing inside add observer instead of inside send |
I think this is still an unsolved problem. Do we still want to put effort into this? |
I was thinking about trying to solve it similar to the |
I've implemented a potential fix here but can't create a PR right now due to a github 500 error. A simple publish benchmark for PublishSubject is 83 MOps/s, BehaviorSubject (new) ~47MOps/s, BehaviorSubject (master) is ~48 MOps/sec. |
Fix just merged. |
Need to investigate the
BehaviorSubject
as it likely has the same problem as Rx.Net as reported here: http://twistedoakstudios.com/blog/Post8424_deadlocks-in-practice-dont-hold-locks-while-notifyingNote that
Subjects
were just re-implemented but kept the same behavior and for theBehaviorSubject
the race between returning the current value and subscribing for subsequent values appears to be wrong.Use case:
The likely bug is that in a race it could receive
3 6 7 8 9
The text was updated successfully, but these errors were encountered: