A lock free version of RxCpp

[david-hoze]

Hi,

I'm using Boost.Asio for my project because it needs to be very performant, and I want to avoid locking, as it is an expensive operation. I would be glad though to use the power of RxCpp to synchronize events. I saw https://github.com/ReactiveX/RxCpp/issues/408, and I was wondering, if indeed I use a lock free scheduler, possibly using Boost.Asio for that, will it eliminate all mutex locking in RxCpp? If not, how hard will it be to eliminate the remaining mutexes and achieve a lock free version of RxCpp?

[kirkshoop]

I do not expect that Asio uses mutex differently than rxcpp. rxcpp is careful to hold a mutex for short periods of time and to never hold over a loop or callback.

looking through github std::mutex is used:

• in the subjects which are used in the publish.. operators.
• in the schedulers new_thread, run_loop etc..
• in the synchronize and serialize coordinations
• in the on operator
• in the composite_subscription

In all cases I believe that the mutex is used to control access to a queue. All but one must be added to a program explicitly. so avoiding these reduces std::mutex usage.

Workarounds for explicit usage

• subjects that are lock-free could be used with multicast to replace publish..
• schedulers that are lock-free could be used.
• coordinations that are lock-free could be used.
• avoid the on operator by using a coordinator directly in the sources (like range and iterate..)

The one unavoidable std::mutex is in the composite_subscription. It is used to access the queue of registered unsubscribe callbacks.

I would measure rxcpp usage with asio in your project to determine if the composite_subscription locking affects your scenarios.