fix(binding): settle two-way bindings and drop needless locks - #100
Merged
Merged
Conversation
- A value waiting for the view's owning thread is replaced by a newer one, so a burst of changes becomes one write. - Bind and BindTwoWay settle on the latest value after two changes from another thread, instead of bouncing values between the view model and the view. - The README and CLAUDE.md describe the latest-value wait, and that Unsafe bindings route writes only through registered invokers.
- InteractionBenchmark measures asking a question through three handlers, and registering and removing handlers. - WhenChangedContentionBenchmark measures two threads changing one observed property at the same time.
- WhenChanged hands a change that arrives during another emit to that emit, so no thread waits on a lock and an observer that waits on such a thread does not deadlock. - An observer that changes the property it observes gets the change after it returns, not inside its own call. - Interaction keeps its handlers in an array replaced on each change, so Handle reads them without a lock or a copy. - Interaction and the binding change stream share one copy-on-write array helper. - RxBindingBuilder tracks initialization with a volatile flag instead of a lock. - BindingHooks reads its cached set with a volatile read and keeps its lock for the resolve after a refresh. - The before-change observables keep their lock, because the value must be read on the raising thread before it writes.
- The benchmark workflow takes no suite or filter and runs all three benchmark projects in full.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #100 +/- ##
==========================================
- Coverage 99.73% 99.72% -0.01%
==========================================
Files 288 289 +1
Lines 11537 11533 -4
Branches 1256 1259 +3
==========================================
- Hits 11506 11501 -5
- Misses 18 19 +1
Partials 13 13 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…mark - Every benchmark takes its jobs and profiler from a shared config: ETW with .NET Framework 4.6.2 on Windows, EventPipe CPU samples and GC events elsewhere. - No benchmark uses the memory diagnoser. - The view models, views and other test data live in Mocks folders, apart from the benchmark classes. - The generator benchmarks read compiled mock consumer source copied beside the assembly. - src/benchmarks/Directory.Build.props holds the settings the benchmark projects share.
…te-latest-value # Conflicts: # src/benchmarks/ReactiveUI.Binding.Benchmarks.ReactiveUI/ReactiveUIBindingBenchmark.cs # src/benchmarks/ReactiveUI.Binding.Benchmarks.ReactiveUI/ReactiveUIObservationBenchmark.cs # src/benchmarks/ReactiveUI.Binding.Benchmarks/RxUiDynamicChainBaseline.cs # src/benchmarks/ReactiveUI.Binding.Benchmarks/UnsafeFallbackBenchmark.cs # src/benchmarks/ReactiveUI.Binding.Benchmarks/WhenAnyDynamicBenchmark.cs # src/benchmarks/Shared/Configs/NativeAotBenchmarkConfig.cs
|
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



What kind of change does this PR introduce?
A bug fix, with a performance improvement.
What is the new behavior?
A two-way binding settles after quick background changes, and hot paths that need no lock take none.
BindandBindTwoWaysettle on the latest value after two quick changes from another thread.Unsafebindings route writes only through registered invokers.WhenChangedhands a change that arrives during another emit to that emit, so no thread waits on a lock.Interactionkeeps its handlers in an array replaced on each change, soHandlereads them without a lock or a copy.Interactionand the binding change stream share one copy-on-write array helper.RxBindingBuildertracks initialization with a volatile flag instead of a lock.BindingHooksreads its cached set with a volatile read.What is the current behavior?
Two quick background changes make a two-way binding bounce values between the view model and the view forever.
WhenChangedemit waits for it, so an observer that waits on that thread deadlocks.What might this PR break?
Nothing a binding relies on.
WhenChangedcan deliver the later value on the thread already emitting.Checklist
mainbranchAdditional information