Enhance AsyncLock to support passing state.

[danielcweber]

No description provided.

[danielcweber]

Up to discussion: Should the public API be enhanced and the new internal method be made public?

[akarnokd]

I'm not convinced this is much of a win. the object state requires structs to be boxed which is equivalent with having a capture of a struct inside a freshly allocated delegate.

[danielcweber]

Right, structs would need to be boxed, but I found most of the time, if something would need to be passed to AsyncLock, it's a class. Besides, if creation of a closure and a delegate could be avoided, it's still a saving of one allocation if boxing occurs.

[danielcweber]

So what's your proposal for a trampoline with state? Duplicate AsyncLock with a generic type parameter?

[akarnokd]

Yes, don't penalize the stateless user places.

[danielcweber]

That would work if all places in a class would only ever pass the same type of state. This might be the case in Rx but it would severely limit the usefulness of AsyncLock. Hence the object parameter.

[akarnokd]

Why would it be public? Support Rx primarily, also T can be object.

[danielcweber]

Will revisit after #558 is merged.

[danielcweber]

@akarnokd Revised the approach. Boxing will still occur when TState is a value type, however, it's still an improvement over closure+delegate.