Implement AsyncLazyInitializer

[sharwell]

This is a supporting type for #30929, but can also support many other use cases where lock-free optimistic initialization is desirable but the initialization function is asynchronous.

[sharwell]

/cc @drewnoakes @stephentoub @AArnott

[AArnott]

FWIW, we recently added an AsyncLazyInitializer to vs-threading. It takes a very different approach, and is JTF aware:

https://github.com/Microsoft/vs-threading/blob/master/src/Microsoft.VisualStudio.Threading/AsyncLazyInitializer.cs

[sharwell]

FWIW, we recently added an AsyncLazyInitializer to vs-threading.

You should rename that type to avoid confusion with LazyInitializer. They address totally separate situations. microsoft/vs-threading#413

and is JTF aware

This type is JTF-agnostic.

[sharwell]

it's a bit odd since hte parameter name is actually 'valueFactory'. Perhaps 'valueFactory' returned null?

This was also taken directly from LazyInitializer:

https://github.com/dotnet/runtime/blob/35795c52d5cfe635152e4c39e037f92a2710c413/src/libraries/System.Private.CoreLib/src/Resources/Strings.resx#L2713-L2715

This comment may not be particularly useful to people (like me) who didn't know what the other one was either...

The new hyperlinking support of Quick Info should help with clarity here. With that said, LazyInitializer''s documentation is "succinct".

In the "we can't deal with IDisposable", why use this class entirely? Is it actually any faster than just inlining the operation?

Overloads are provided that support automatically releasing unused values.

Why is this broken into a separate method vs just inlined?

Each helper is now used from two locations.

I must admit, this feels really screwy. I get it, but it seems like us lifting local variables in the lambda and such would offset some of the benefits of this...?

I'm not aware of an alternative. The API is still cleaner than trying to inline the functionality correctly.

Why not break into separate test methods?

Done.

I admit the test name predisposed me to think "firstInitializedValueTask" would be the one that is taken. The code is right, the naming was a bit offputting though.

Adding some comments to clarify the weirdness here.