在RX中，处理线程安全是消费者（IOBSERVER）的责任吗？

发布于 2025-02-03 09:32:54 字数 385 浏览 3 评论 0原文

在Reactivex范式中，是消费者的责任（iObserver）来处理线程安全吗？

例如，如果on Completed呼叫在onNext仍在另一个线程上执行时会出现吗？

它看起来像从rx .net源中，但是文档有些模糊。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

吻风 2025-02-10 09:32:54

由于我最初在a

似乎我假设线程安全序列化是消费者的责任（iobserver）。

根据原始 RX设计指南文档（看起来是最佳的秘密:)

4.2。假设观察者实例以序列化的方式调用
当rx使用推动模型和.NET支持多线程，它是
不同消息可能到达不同的执行上下文
同时。如果可观察到的序列消费者必须
在每个地方处理这个问题，他们的代码需要执行很多
避免常见并发问题的管家。编写的代码
这种时尚将很难维持和可能遭受
性能问题。

更远：

6.7。在可观察到的序列实现中序列化IOBSERVER方法RX是可综合的API，许多操作员可以播放
一起。如果所有操作员都必须处理并发，则
操作员将变得非常复杂。接下来，并发是最好的
首先发生在该地点。最后，消耗RX API
如果RX的每次使用都必须处理，将会变得更加困难
并发。

最后：

6.8。避免序列化操作员，因为所有RX操作员都必须使用指南6.7，操作员可以安全地假设其输入是
序列化。添加过多的同步会使代码混乱，并且
可能导致性能降解。如果可观察到的序列不是
遵循RX合同（请参阅第0章），取决于开发人员
编写最终用户应用程序以通过
呼叫开发人员获得的操作员首先
可观察到的序列。这样，附加的范围
同步仅限于需要的位置。

我个人的看法：如果产生iObservable的原始序列可以在调用onNext，onerror，oncomplete >（或当处置时，请在其订阅中调用），应该注意正确地序列化这些呼叫。

Since I initially asked this question in a tweet, I believe I've now found an authoritative answer.

It appears I was wrong in my assumption that thread-safe serialization is the consumer's responsibility (IObserver).

According to the original Rx Design Guidelines document (a best-kept secret as it seems :)

4.2. Assume observer instances are called in a serialized fashion
As Rx uses a push model and .NET supports multithreading, it is
possible for different messages to arrive different execution contexts
at the same time. If consumers of observable sequences would have to
deal with this in every place, their code would need to perform a lot
of housekeeping to avoid common concurrency problems. Code written in
this fashion would be harder to maintain and potentially suffer from
performance issues.

Further:

6.7. Serialize calls to IObserver methods within observable sequence implementations Rx is a composable API, many operators can play
together. If all operators had to deal with concurrency the individual
operators would become very complex. Next to this, concurrency is best
controlled at the place it first occurs. Finally, Consuming the Rx API
would become harder if each usage of Rx would have to deal with
concurrency.

And finally:

6.8. Avoid serializing operators As all Rx operators are bound to guideline 6.7, operators can safely assume that their inputs are
serialized. Adding too much synchronization would clutter the code and
can lead to performance degradation. If an observable sequence is not
following the Rx contract (see chapter 0), it is up to the developer
writing the end-user application to fix the observable sequence by
calling the Synchronize operator at the first place the developer gets
a hold of the observable sequence. This way the scope of additional
synchronization is limited to where it is needed.

My personal take from this: if an original sequence producing IObservable can introduce parallelism when it calls OnNext, OnError, OnComplete (or when Dispose is called on its subscription), it should take care to serialize these calls properly.

回复收藏 0 原文

~没有更多了~