-1

Have a scenario where we are measuring the cpu time in a C# async flow. What we are observing is that the thread id before a await and after await or not same.

As example we are getting the thread id using the following - NativeMethods.GetCurrentThreadId().

The code is as follows:

startThreadId = NativeMethods.GetCurrentThreadId()
var result = await ExecuteCommand();
endThreadId = NativeMethods.GetCurrentThreadId()
return result;

In the above code sample, the startThreadId and endThreadId are different and not matching. Any guidance on how to ensure that the thread id is same or it would never be the case with async await pattern ?

Thanks

Venki
  • 2,085
  • 5
  • 30
  • 51
  • 7
    The usual follow up for questions about threads is, "Why does it matter (to your code) which thread your code is running on?" There are legitimate reasons, but please expand on why your code needs to resume on the same thread (unless this is a hypothetical question?). – D M May 13 '22 at 16:52
  • 1
    That is one of the main benefits of using async/await. The thread is released to service other request while the I/O completes. Then execution resumes on the first available thread. This allows applications that might otherwise become thread starved due to high I/O latency to continue to function and be responsive. There usually is never a good reason to want to continue execution on the same thread and if you are encountering a reason please update your question because likely there is a built in way around it (like having the UI culture persist across the call for example). – Igor May 13 '22 at 16:56
  • 1
    Unless you can explain **why** you think it matters that the thread that continues the work is the same, we cannot help you. What exactly do you want to do **after** the `await` call that would require the same thread to pick up the code? – Camilo Terevinto May 13 '22 at 17:07
  • May be I did not frame the question properly. Wanted to measure the total amount of time that the thread spent using the CPU. The goal is to measure the CPU time for an operation. Using the https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getthreadtimes for the same. GetThreadTimes take a thread id. lpKernelTime and lpUserTime are FILETIME structures that map directly to a long (64 bit number). These numbers represent the number of 100-nanoseconds, ticks, executed in CPU (kernel and user mode respectively) since the thread has been created. – Venki May 13 '22 at 17:13
  • 1
    You could check out [this](https://stackoverflow.com/questions/52686862/why-the-default-synchronizationcontext-is-not-captured-in-a-console-app/68588200#68588200) answer that shows how to use the static `AsyncContext` class from the [`Nito.AsyncEx.Context`](https://www.nuget.org/packages/Nito.AsyncEx.Context/) package, in order to run your asynchronous method in a synchronization context that will resume the execution on the same thread after the `await`. – Theodor Zoulias May 13 '22 at 17:14
  • In a non async scenario, we get the thread time at the beginning of the operation and then thread time at the end of the operation. Then do a diff to get the total Cpu time. – Venki May 13 '22 at 17:15
  • 2
    @Venki ideal async method takes zero CPU time and runs for a day... You can't really hack up real profiling that way as you have zero control over what thread actual code for async operation would run. You can easily measure sync portion before and after await (since either parts runs on a single thread)... Just use real profiler or figure out exactly what you hope to achieve more carefully. – Alexei Levenkov May 13 '22 at 17:37
  • We are having an asp.net application where we do custom serialization with formatters and then the entire code path is using async await. We read a chunk, then do some base64 processsing and then write the chunk. In this the reading the chunk and writing the chunk are await operations. So the only thing that can be measured is the code in between. Is that what you are suggesting @alexeilevekov ? – Venki May 14 '22 at 03:15

0 Answers0