Add concurrency data structures for TPL

[chriskuech]

Is your feature request related to a problem? Please describe.

A reoccurring problem I see with ASP.NET Core web services is caching data from an API. Currently this manifests in two primary scenarios:

1. Lazily caching a single request on a field.
2. Lazily caching many requests by a key in a ConcurrentDictionary.

Both of these scenarios have suboptimal solutions. System.Lazy does not support async value factory functions and async/await does not work in a lock, so mitigation requires mixing semaphores boilerplate with TPL. System.Concurrency classes don't support async value factory methods, which results in caching Tasks and messy error handling and cache management code around the stored Tasks.

Describe the solution you'd like

Support async value factory function parameters in System.Concurrency and System.Lazy, so that API calls can be made in factory functions and only the result is cached, rather than caching the whole Task.

[javiercn]

@chriskuech thanks for contacting us.

This is not the right repository for this ask. In order for you to get a better and faster answer we are transferring this to the runtime repository where they'll be able to help you.

That said, if I understood correctly what you are saying, I don't think using such low level features is the right way to approach the problem you are facing. ASP.NET core already offers IMemoryCache and other higher level primitives that will help you better manage this issue.

As for the "Async support" for Lazy and ConcurrentDictionary, nothing prevents your factory from returning a Task that you can then await to get the result, that way your factory function only runs once and subsequent calls just receive the same task, which they can then await to get the value you need.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[chriskuech]

@javiercn , thanks for the quick triage. We do currently store Tasks as you describe, but this leads to some messy error handling code to avoid caching errors and to avoid the appearance of multiple erroring requests instead of one. I will see if memcache can solve the second scenario.

[ghost]

Tagging subscribers to this area: @tarekgh See info in area-owners.md if you want to be subscribed.

[stephentoub]

Is there a concrete proposal here for new APIs? Seems like the scenarios are already achievable via other means. If that's the case, we can just close this. Thanks.

[ghost]

This issue has been marked needs-author-action since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

[ghost]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[ghost]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.