.net core 3控制器中的并发/任务问题

Question

I have a question on tasking/blocking/async on a controller setup in .net core 3. I've got the main controller methods set up as async, but have a question about how to handle downstream async calls within it

I have code working, just wondering if it's done optimally.

Controller code (methods of interest to this discussion), _verseReader was injected, and is an interface, and startup.cs could set this up based on config to read from almost any storage (xml, sql, mysql, cosmos, mongo, etc)...the controller doesn't care what storage is being used. It's all async, so the actual "reading" is done as a task.

...
[HttpGet("{translation}")]
        public async Task<ActionResult<List<VerseSet>>> GetVerses([FromRoute] string Translation, [FromQuery] string Verse, [FromQuery] bool IncludeVerseNumbers=true)
        {
            VerseService vs = new VerseService(_verseReader);
            var backgroundTask = Task.Run(() => vs.GetVerses(Translation, Verse, IncludeVerseNumbers));
            var vList = await backgroundTask;
            return vList == null ? (ActionResult)NotFound(vList) : Ok(vList);
        }
...

vs.GetVerses is NOT setup async (because this was already all async) from the controller. it makes a call to ReadVerses, which does some processing, parsing and setup:

 public List<VerseSet> GetVerses(string TranslationName, string VerseMatchSpec, bool IncludeVerseNumbers)
        {
            List<VerseSet> vList = new List<VerseSet>();
            ...
            VerseSet v = ReadVerses(TranslationName, s, IncludeVerseNumbers);
            ...
            return vList;
        }

ReadVerses looks like:

 private VerseSet ReadVerses(String TranslationName, String VerseMatchSpec, bool IncludeVerseNumbers)
        {
           ...some code here
            List<VerseInfo> theVerseInfo = _verseReader.ReadFromStorage(v.Translation, vs.bookname, vs.chapter, vs.v1, vs.v2);
           ...some code here
            return v;
        }

Now it's the ReadFromStorage method (of the injected class) which actually calls out to obtain the data from whatever storage source was setup in config (Xml, SQL, Mongo, etc). Everything is done sync, because this was all already spawned in a Task by the controller. However, for CosmosDB, it MUST use async calls, so I'm forced to do (see the call to .Result!). I must do this because ReadFromStorage is not designated async.

 public List<VerseInfo> ReadFromStorage(String Translation, String Bookspec, int Chapter, int StartingVerse, int EndingVerse)
        {
            ...code here
            var bookResult = client.CreateDocumentQuery<CosmosBook>(UriFactory.CreateDocumentCollectionUri(_connInfo["DatabaseId"], "books"), new FeedOptions { EnableCrossPartitionQuery = true , MaxItemCount = 1})
                .Where(b => b.Matchspec.Contains($"[{Bookspec}]"))
                .AsDocumentQuery()
                .ExecuteNextAsync<CosmosBook>().Result;
            ...code here
            return vList;
         }

I've read up on .Result and it seems blocking (of course) so I'm wondering if this is a bad setup. It's all already within a spawned task by the main controller method. If I were to try to use await here, I must make the ENTIRE calling chain async?!? That's my question. From what I understand, I'd have to make ReadFromStorage async, then ReadVerses also async, then even further GetVerses async. So I'm wondering what is best in this case. Is .Result ok?

And is there some way of doing await's without making the ENTIRE calling stack async also (which would force tasks to be created at 4 different times)...which seems silly (and slow).

There's no error message, The code works fine as is... it's a question on optimization. It seems very confusing that you'd have to make (change code) of all callers to be async, just to use await down in a call stack somewhere? Or maybe I'm missing something. Thanks.

Answer 1

I've refactored all the code in to async, and it all makes sense now, and is more coherent (and correct). I also added "Async" suffix to my class reader method calls, to conform to convention.

After reading for 4 hours now about Tasks and await/async, I better understand the differences between "tasks" and "threads" (they are not the same thing). Coming from other languages, "Task" usually was used to mean "Start New Thread", so that was causing a lot of confusion, as I was under the impression that adding await/async on methods started new threads for each method called. But that is not the case. New threads are only started when Task.Run is called explicitly, and typically only used for sending compute intensive routines to a background THREAD, for processing. Maybe this helps others who are encountering .net async/await (and .net Tasks) for the first time.

[HttpGet("{translation}")]
        public async Task<ActionResult<List<VerseSet>>> GetVerses([FromRoute] string Translation, [FromQuery] string Verse, [FromQuery] bool IncludeVerseNumbers=true)
        {
            VerseService vs = new VerseService(_verseReader);
            List<VerseSet> vList = await vs.GetVerses(Translation, Verse, IncludeVerseNumbers);
            return vList == null ? (ActionResult)NotFound(vList) : Ok(vList);
        }

   public async Task<List<VerseSet>> GetVerses(string TranslationName, string VerseMatchSpec, bool IncludeVerseNumbers)
        {
            ...
            VerseSet v = await ReadVerses(TranslationName, s, IncludeVerseNumbers);
            ...
            return vList;
        }

private async Task<VerseSet> ReadVerses(String TranslationName, String VerseMatchSpec, bool IncludeVerseNumbers)
        {
            ....
            List<VerseInfo> theVerseInfo = await _verseReader.ReadFromStorageAsync(v.Translation, vs.bookname, vs.chapter, vs.v1, vs.v2);
            ...
        }

Answer 2

If I were to try to use await here, I must make the ENTIRE calling chain async?!? That's my question.

Yes. You should go async all the way .

Is .Result ok?

It's "ok" in the sense that it would work (ie, not cause a YSOD). However, on ASP.NET, either Result or Task.Run will artificially limit your server's scalability .