Lock-free subscriptions

[akarnokd]

• Uniform naming of inner components: Issue SerialSubscription and SingleAssignementSubscription naming, Subscriptions in general #592
• Lock-free approach to avoid deadlocks: Issue Deadlock in 0.15.x between MultipleAssignmentSubscription and CompositeSubscription #577
• SerialSubscription.isUnsubscribe added: Issue SerialSubscription is missing isUnsubscribed #590

Remarks:

• IMO, an unsubscribed Single/Serial/Multiple subscription return Subscriptions.empty() instead of null. So unless the user put a null in there he/she shouldn't worry about null.
• There was a concurrency bug in @jloisel 's reimplementation of CompositeSubscription. It allowed multiple threads to enter the mutation part if the current state was already MUTATE. I've added the necessary checks to allow only NORMAL -> MUTATE transitions.

[jloisel]

It cannot return Subscriptions.empty(), since the Rx contract is to return null. Also, returning empty() when unsubscribed is ambiguous: has it been unsubscribed or has empty() been set by the client code ?

[cloudbees-pull-request-builder]

RxJava-pull-requests #527 SUCCESS
This pull request looks good

[jloisel]

Good that you fixed the race condition in MultipleAssignementSubscription as well as the contract. (it was unsubscribing the previous subscription although it shouldn't)

[akarnokd]

I've checked the Rx.NET sources:

• SingleAssignmentDisposable returns DefaultDisposable.Instance
• SerialDisposabe returns null
• RefCountDisposable returns Disposable.Empty
• ScheduledDisposable returns DefaultDisposable.Instance

So my question is, why only SerialDisposable returns null? Checking the return of the getSubscription to determine if unsubscription happened is wrong since SerialSubscription can be started with null; this is why isUnsubscribed() is to be used to check the state.

[headinthebox]

It cannot return Subscriptions.empty(), since the Rx contract is to return null.

I don't think that is actually this strict; that is what the implementation does; I think it is better to return empty than null. The real "state" is is isUnsubscribed (and the properties might as well be write-only)

[jloisel]

I think the disposable / subscription contract lakes precision and uniformity. It doesn't matter to return null or empty, what matters is a constant behavior, following the "least astonishment" principle