`Signal` lock elision. #129

andersio · 2016-11-28T23:49:07Z

While we advocate for a safe-by-default API like how our beloved Swift does, there are places we may elide the serialization:

Synchronously Signal operators. e.g. map, filter, scan, skipNil.

These can rely on the serialization at the ultimate upstream, e.g. signals created by Signal.init or Signal.pipe with default settings.

An illustration of how the call stack would look like with signal.map(t).map(t).map(t).map(t)...:

sendLock
observers ---> [sendLock]
               observers    ---> [sendLock]
                                 observers    ---> [sendLock]
                                                   observers    ---> ...
                                                   [unlock]
                                 [unlock] <---/
               [unlock] <---/
unlock    <---/

Asynchronous Signal operators which deliver all kinds of events on the same Scheduler.

For example, observe(on:) forwards all the events to the supplied Scheduler. Since the scheduler serialises all the enqueued actions, there is no need for the created signal to serialise the events again.
Signals that are owned by synchronized entities.

For entities that are already synchronised, Signal can safely assume events not to be emitted concurrently. For example, MutableProperty always sends event in its critical section.

Implementation

The PR introduces an optional parameter attributes to Signal.init and Signal.pipe that allows configurability of some of the Signal behavior.

For the purpose of the PR, a inheritSerialization option was introduced. Signals created with this flag would not attempt to serialise the inputs it received.

sharplet · 2016-11-29T00:35:28Z

Sources/Signal.swift

+			func sendLockLock() {
+				if let lock = sendLock {
+					lock.lock()
+				}


This could be shortened to lock?.lock()

sharplet

This seems like a pretty reasonable idea, and it's not a big change.

Are there any ramifications for existing code that might start signals as a side effect in on() or some other operator? What would happen to recursive event sending that currently results in a deadlock — anything?

sharplet · 2016-11-29T00:36:10Z

Sources/Signal.swift

+				if let lock = sendLock {
+					return lock.try()
+				}
+				return true


This could be shortened to return lock?.try() ?? true

sharplet · 2016-11-29T00:36:28Z

Sources/Signal.swift

+			func sendLockUnlock() {
+				if let lock = sendLock {
+					lock.unlock()
+				}


This could be shortened to lock?.unlock()

sharplet · 2016-11-29T00:37:11Z

Sources/Signal.swift


 		let observer = Observer { [weak self] event in
 			guard let signal = self else {
 				return
 			}

 			@inline(__always)
+			func sendLockLock() {


What do you think about just naming this lock()?

sharplet · 2016-11-29T00:37:30Z

Sources/Signal.swift

+			}
+
+			@inline(__always)
+			func sendLockTryLock() -> Bool {


What do you think about just naming this tryLock()?

sharplet · 2016-11-29T00:37:41Z

Sources/Signal.swift

+			}
+
+			@inline(__always)
+			func sendLockUnlock() {


What do you think about just naming this unlock()?

sharplet · 2016-11-29T00:38:29Z

Sources/Signal.swift

 	///   - disposable: An optional disposable to associate with the signal, and
 	///                 to be disposed of when the signal terminates.
 	///
 	/// - returns: A tuple made of signal and observer.
-	public static func pipe(disposable: Disposable? = nil) -> (Signal, Observer) {
+	public static func pipe(_ concurrency: SignalConcurrency = .serialized, disposable: Disposable? = nil) -> (Signal, Observer) {


I think this should be a named parameter.

sharplet · 2016-11-29T00:38:48Z

Sources/Signal.swift

 	///   - generator: A closure that accepts an implicitly created observer
 	///                that will act as an event emitter for the signal.
-	public init(_ generator: (Observer) -> Disposable?) {
+	public init(_ concurrency: SignalConcurrency = .serialized, _ generator: (Observer) -> Disposable?) {


I think this should be a named parameter.

sharplet · 2016-11-29T00:43:40Z

Sources/Signal.swift

+	/// The `Signal` may assume the events emitted to it have already been 
+	/// serialized. In other words, the event emitter of the `Signal` is assumed
+	/// to only be called in synchronized routines.
+	case contained


I'm not sure about the naming — how about this?

public enum SignalSerialization { case mutex case inherit } Signal(serialization: .mutex) { observer in // ... } Signal.pipe(serialization: .inherit)

sharplet · 2016-11-29T00:44:51Z

Sources/Signal.swift

@@ -187,13 +219,16 @@ public final class Signal<Value, Error: Swift.Error> {
 	///         retained.
 	///
 	/// - parameters:
+	///   - contained: Indicates if the event emitter passed to `generator` would


This comment will need to be updated when the name is finalised.

sharplet · 2016-11-29T00:45:14Z

Sources/Signal.swift

@@ -35,9 +35,11 @@ public final class Signal<Value, Error: Swift.Error> {
 	///         Signal itself will remain alive until the observer is released.
 	///
 	/// - parameters:
+	///   - concurrency: The concurrency mode the signal should assume.


This comment will need to be updated too.

andersio · 2016-11-29T01:20:15Z

Are there any ramifications for existing code that might start signals as a side effect in on() or some other operator?

If you mean starting producers, I don't see it would cause harm.

Edit: Recursive event sending was not allowed since the very beginning. So other than this, the side effects are still executing within the same giant protected section, in the very same order, unless ~~asynchronous~~ operators that involves multiple signals are used.

If you mean observing any Signal along the chain, the observer bag is CoW on insertion or removal.

What would happen to recursive event sending that currently results in a deadlock — anything?

Obviously, the unlocked mode would grant a hole for recursive event sending. But our stance should remain unchanged. ~~One way we could do this is allowing lock elision only in release builds~~ (Edit: though I'd prefer to have it in debug builds, and we could simply declare it unsupported and "don't call us when you crashed".)

As for recursive interrupted handling, since we are just dealing with Signals here, the only source of interrupted events would be the upstream, i.e. no difference from other events.

Edit: It is a different story to have SignalProducer's lock elided, but we should leave it to another PR.

NachoSoto

Before I look deeper I wanted to say that I'm 👎 for making this part of the public API. I'm okay if we use it as an optimization internally, but I think the increase in complexity of the API wouldn't be justified.

andersio · 2016-11-29T02:29:30Z

@NachoSoto Has to be part of the public API, or otherwise RAC can't use ~~them~~ it.

Edit: Having said that, RAC APIs may still enjoy the benefits as users apply more and more operators. But it feels sad (?) to me not to have RAC covered too.

Edit 2: There is a middle ground though: obscurity. We can export this API to ~~a submodule~~ an enum namespace, say ReactiveSwift.UtterlyUnsafe.

andersio · 2016-11-29T02:36:52Z

Renamed a few stuff according to @sharplet's suggestions, and had four operators joined their lock-elided friends in 1dd6d5f.

andersio · 2016-11-29T04:32:56Z

A note on the recursive interrupted handling:

AFAIU, it is made for SignalProducer specifically. However, as we are not addressing SignalProducer yet, it is simply assumed to never happen with inherited serialization, since interrupted is only sent on the Signal the producer created, which still uses the default serialization.

 lock
 observers ---> lock
                observers ---> elidedLock
                               observers    ---> lock
                                                 observers    ---> elidedLock
                                                                   observers    ---> ...
                                                                   elidedUnlock
                                                 unlock       <---/
                               elidedUnlock <---/
                unlock    <---/
 unlock    <---/
------------------------------------------------------------------------------------
    SOURCE    |   PRODUCER   |   LIFTED MAP    |    PRODUCER     |   LIFTED MAP    | ...
------------------------------------------------------------------------------------

 Sources can be:
 1. Properties
 2. `SignalProducer(signal:)`
 3. `SignalProducer(_:)` (not necessarily serialised.)

Edit: Updated the ASCII diagrams. The unlocks are misplaced. 🙈
Edit 2: Added the missing "Source" column.

sharplet · 2016-11-29T04:43:14Z

Sources/Signal.swift

+
+	/// The `Signal` assumes to have inherited the serialization from its owner,
+	/// and its event emitter would not be called concurrently.
+	case inherited


FWIW, I still think this case would read better as an imperative: Signal(serialization: .inherit)

Followed FlattenStrategy to use imperative verbs.

sharplet · 2016-11-29T05:19:34Z

Sources/FoundationExtensions.swift

@@ -29,7 +29,7 @@ extension Reactive where Base: NotificationCenter {
 	/// - note: The signal does not terminate naturally. Observers must be
 	///         explicitly disposed to avoid leaks.
 	public func notifications(forName name: Notification.Name?, object: AnyObject? = nil) -> Signal<Notification, NoError> {
-		return Signal { [base = self.base] observer in
+		return Signal(strategy: .inherit) { [base = self.base] observer in


I think we've lost too much meaning now at the point of use. It's no longer clear what's being inherited.

Does inputStrategy or serializeStrategy make sense to you?

I'd say serializationStrategy.

However, I'm still partial to serialization: .default and serialization: .inherit. What do you think?

...with declaration: init(serialization strategy: SerializationStrategy, ...).

Sometimes I do wonder if FlattenStrategy should be FlatteningStrategy instead...

NachoSoto

If it can't be private then like I said I don't think the benefits warrant the increase in complexity. This is exposing implementation details that most users won't care about 👎

andersio · 2016-11-29T17:34:32Z

@NachoSoto Maybe I should have phrased it better: It can for sure be private to ReactiveSwift.

I just want to figure out a middle ground for RAC if it makes sense. If "internal" through obscurity (like stdlib) is still considered exposing the implementation, there is probably no other way to expose this to RAC based on my understanding.

Edit: For example:

public enum __WhenWeDoNotHaveSubmodulesThisHappens {
	public static func __makeInheritlySerializedSignal<Value, Error: Swift.Error>(
		_ generator: @escaping (Observer<Value, Error>) -> Disposable?
	) -> Signal<Value, Error> {
		return ReactiveSwift.Signal(serialization: .inherit, generator)
	}
}

andersio · 2016-12-02T04:47:18Z

@NachoSoto Hmm, I actually thought of a counter argument to keeping it private: while most users would not care, users - including depending libraries like ReactiveCocoa - who want custom operators or have all possible means to optimize should be given the tools.

If what you worry is having it ~~as part of the normal overload~~ showing up in code completion, as mentioned we could export it in an separate enum namespace.

andersio · 2016-12-02T05:57:49Z

Benchmark Source
Environment: macOS Sierra 10.12.1, i5 4258U, Xcode 8.1, -Owholemodule
Comparing against master.

TableView Scrolling Simulation
Producer heavy, Produced signals send only 1 value.
+2% (7%)

Send 10000 values to 1 observer.
+9% (10%)

Send 10000 values to 8 observers.
+12% (5%)

Send 10000 values to 1 produced signal.
+4% (8%)

Send 10000 values to 8 produced signals.
+6% (3%)

andersio · 2016-12-03T16:56:45Z

Blocked by #137.

andersio · 2017-01-14T02:37:40Z

The SignalSerialization enum is replaced with an option set, since I expect #163 would need a similar way to customise the Signal. ~~The APIs are also promoted back to be public, primarily for depending frameworks and users writing custom operators.~~

~~Note that as a default attribute set is provided, Signal.init and Signal.pipe shows up in autocomplete as two overloads.~~

andersio · 2017-04-28T20:16:51Z

Rolled back to be an internal API, and rebased on master. The benefit of opening it up for the sourcing signals in RAC is trivial and not a priority, since the primary concern is cutting the overhead of deep signal composition.

andersio · 2017-05-30T07:17:52Z

Benchmark source.

Test body

		let property = MutableProperty((0, 0, 0, 0))
		let composed = { property.map { ($0.1, $0.3) }.combinePrevious((-1, -1)) }()
		//let (signal, observer) = Signal<(Int, Int, Int, Int), NoError>.pipe()
		//let composed = signal.map { ($0.1, $0.3) }.combinePrevious((-1, -1))

		withExtendedLifetime(composed) {
			_measureAndStart(times: 1_000_000, label: label) {
				let value = 1
				//observer.send(value: (value, value, value, value))
				property.value = (value, value, value, value)
			}
		}

Result
1000000 iterations, -Owmo, i5 6260U

// Signal, `observer.send(value:)`
@testNonatomic(): avg 1570 ns; min 1343 ns
@testNormal(): avg 1644 ns; min 1422 ns

// MutableProperty, `property.value.set`
@testNonatomic(): avg 5402 ns; min 4656 ns
@testNormal(): avg 5578 ns; min 4797 ns

The locking overhead is around 5-7% per observer call-out.

For the narrower gap in properties, it is likely due to not having lifting optimization (#140) in place, which elides the serialising, relaying Signal of lifted operators for the concurrent interruption, and allows serialisation and interruption to be inherited from upstreams. Recall that composed properties use SignalProducer at its core.

mdiep

I'm not very excited about this. The thread safety is already hard to reason about without adding an additional level of complexity. I'm not eager to make it any more complex, especially for modest performance gains.

mdiep · 2017-06-03T19:38:57Z

Sources/Signal.swift

-		fileprivate init(_ generator: (Observer) -> Disposable?) {
+		fileprivate init(_ attributes: SignalAttributes, _ generator: (Observer) -> Disposable?) {
+			var attributes = attributes
+			if (Thread.current.threadDictionary["reactiveswift_disable_inherit_serialization"] as! Bool?) ?? false {


What's this for?

Ah, I forgot to revert this hack for benchmarking purpose. 🤦‍♂️

mdiep · 2017-06-03T19:41:19Z

Sources/Signal.swift

+}
+
+/// Describes how `Signal` should behave.
+internal struct SignalAttributes: OptionSet {


Why an OptionSet instead of an enum?

andersio · 2017-06-03T20:04:21Z

The thread safety is already hard to reason about without adding an additional level of complexity.

The annotation in this PR is built on top of the premises of the Signal contract, saying all Signals must be synchronous (by default) and serialized.

If a synchronous operator derives a Signal from one single upstream, the derived Signal is already implicitly serialized — like a synchronous call tree that starts within a critical section. The keywords are synchronous and single upstream, which are fairly explicit IMO.

andersio · 2017-07-16T19:40:29Z

Closed since this becomes trivial with an upcoming higher-level SignalProducer optimisation branch.

sharplet reviewed Nov 29, 2016

View reviewed changes

sharplet requested changes Nov 29, 2016

View reviewed changes

NachoSoto requested changes Nov 29, 2016

View reviewed changes

sharplet reviewed Nov 29, 2016

View reviewed changes

sharplet requested changes Nov 29, 2016

View reviewed changes

andersio force-pushed the lock-elision branch 5 times, most recently from fa79195 to c44539b Compare November 29, 2016 17:21

NachoSoto requested changes Nov 29, 2016

View reviewed changes

andersio force-pushed the lock-elision branch from c44539b to 25123dd Compare November 29, 2016 17:28

andersio force-pushed the lock-elision branch 2 times, most recently from 05c3796 to 035d46c Compare November 29, 2016 22:38

andersio added blocked and removed blocked labels Dec 1, 2016

andersio force-pushed the lock-elision branch from 1334b0d to b12d6bc Compare December 2, 2016 06:09

mdiep added the optimization label Dec 2, 2016

andersio mentioned this pull request Dec 2, 2016

Allow all termination events to be recursively sent. #137

Merged

andersio added the blocked label Dec 3, 2016

andersio removed the blocked label Dec 15, 2016

andersio force-pushed the lock-elision branch from fde92fd to 24f35b2 Compare December 16, 2016 02:04

andersio mentioned this pull request Dec 25, 2016

[WIP] Composed properties internal refactoring + observe(on:). #166

Closed

andersio force-pushed the lock-elision branch from 24f35b2 to 11046d4 Compare December 31, 2016 03:12

andersio added additive and removed optimization labels Apr 15, 2017

andersio removed the additive label Apr 24, 2017

andersio force-pushed the lock-elision branch from 18c9e7d to b6592b0 Compare April 28, 2017 20:09

andersio requested review from sharplet and NachoSoto April 28, 2017 20:13

andersio force-pushed the lock-elision branch from b6592b0 to 46b69a2 Compare April 28, 2017 20:44

andersio force-pushed the lock-elision branch from 46b69a2 to aaabccb Compare May 15, 2017 14:08

andersio force-pushed the lock-elision branch from aaabccb to e0d0ce9 Compare May 30, 2017 07:09

mdiep reviewed Jun 3, 2017

View reviewed changes

andersio force-pushed the lock-elision branch 3 times, most recently from fff4f32 to 420a3ed Compare June 4, 2017 05:51

Signal lock elision.

445d27c

andersio force-pushed the lock-elision branch from 420a3ed to 445d27c Compare June 4, 2017 05:54

andersio mentioned this pull request Jun 15, 2017

Improve Signal state management to avoid an ARC race. #456

Merged

andersio closed this Jul 16, 2017

andersio deleted the lock-elision branch July 16, 2017 19:40

andersio mentioned this pull request Jul 17, 2017

Cutting the SignalProducer overhead further. #487

Merged

1 task

Signal lock elision. #129

Signal lock elision. #129

Conversation

andersio commented Nov 28, 2016 • edited Loading

Implementation

sharplet Nov 29, 2016 • edited Loading

Choose a reason for hiding this comment

sharplet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio commented Nov 29, 2016 • edited Loading

NachoSoto left a comment

Choose a reason for hiding this comment

andersio commented Nov 29, 2016 • edited Loading

andersio commented Nov 29, 2016

andersio commented Nov 29, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

NachoSoto left a comment

Choose a reason for hiding this comment

andersio commented Nov 29, 2016 • edited Loading

andersio commented Dec 2, 2016 • edited Loading

andersio commented Dec 2, 2016 • edited Loading

andersio commented Dec 3, 2016

andersio commented Jan 14, 2017 • edited Loading

andersio commented Apr 28, 2017 • edited Loading

andersio commented May 30, 2017 • edited Loading

mdiep left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio commented Jun 3, 2017 • edited Loading

andersio commented Jul 16, 2017

`Signal` lock elision. #129

`Signal` lock elision. #129

andersio commented Nov 28, 2016 •

edited

Loading

sharplet Nov 29, 2016 •

edited

Loading

andersio commented Nov 29, 2016 •

edited

Loading

andersio commented Nov 29, 2016 •

edited

Loading

andersio commented Nov 29, 2016 •

edited

Loading

andersio commented Nov 29, 2016 •

edited

Loading

andersio commented Dec 2, 2016 •

edited

Loading

andersio commented Dec 2, 2016 •

edited

Loading

andersio commented Jan 14, 2017 •

edited

Loading

andersio commented Apr 28, 2017 •

edited

Loading

andersio commented May 30, 2017 •

edited

Loading

andersio commented Jun 3, 2017 •

edited

Loading