async

Qwen 3.8 is out since Friday, 17 of August. I am running it on my own server since Saturday. I am running Q4 quants from unsloth .

So far it feels like a step up from Qwen 3.6 27B, which sometimes had problems figuring stuff in my project that I am developing almost entirely using models - just as a test of how far I can push LLMs in agentic coding - mostly local models, I must add. Qwen 3.8 seems like having no problem at all.

• IDisposable

  • SupressFinalize in IDisposable

• Asynchronous programming in .NET

  • async/await
  • Avoid deadlock with async/await
  • Does async/await creates new thread?
  • CPU bound vs I/O bound tasks
  • SynchronizationContext
  • Threads/tasks
  • locking in .NET
    • locking with integer
  • TPL
  • ThreadPool

• Type system

  • Reference types vs value types
    • value types as fields in objects
  • What kind of types cannot be object field?
  • ref struct types
  • Strings in .NET
  • Data Structures
  • Generics
  • Covariance and Contravariance
  • Equals and GetHashCode

• Garbage Collector

There are 2 ways of writing OWIN middleware in ASP.NET Core.

• Pure OWIN - usefull if you want to integrate with OWIN compatible module but not written in C#
• ASP.NET Core OWIN middleware

ASP.NET Core Middleware:

This type of middleware can be:

• delegate of Func<HttpContext, Func<Task>, Task>
• class with IMiddleware imlementation

app.Use(async (context, next) =>
{
    // Do work that can write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

Pure OWIN Middleware:

This rather would be used to integrate with OWIN middlewares written in different language, so that ASP.NET Core implementation directly is not possible.

In short: no.

Longer explanation:

• task that want to do I/O write call to driver write
• driver operations are performed asynchronously
• write operations on devices is done without CPU involved
• finish of writing is done via interrupt
• interrupt, schedules Deferred Procedure Call
• DPC schedules Asynchronous Procedure Call
• APC notifies thread that I/O write is done
• task that was doing I/O is scheduled with continuation of its method after I/O is done.
• some threads might need to be borrowed for handling APC and such but no thread is spawn to handle I/O

I recommend reading this post: https://blog.stephencleary.com/2013/11/there-is-no-thread.html . This will explain the topic much better than I can.

async/await syntax should be used for I/O bound asynchronous operations only.

public async Task<int> GetUrlContentLengthAsync()
{
    var client = new HttpClient();

    Task<string> getStringTask =
        client.GetStringAsync("https://docs.microsoft.com/dotnet");

    DoIndependentWork();

    string contents = await getStringTask;

    return contents.Length;
}

Compiler transforms code into a state machine that to track yielding execution for await and resuming execution when a background job is finished.

Things to keep in mind:

• async method needs await
• add Async suffix to asynchronous methods
• async void for ‘Fire and Forget’ work i.e. event Handlers
• be aware of mixing LINQ with async lambdas
• wait for tasks in a non-blocking manner (do not use Task.Result i.e.)
• for tight loops use ValueTasks
• Consider using ConfigureAwait(false) for performance and for avoiding deadlocks

Further read:

There are two types of asynchronous operations in .NET.

• I/O bound
• CPU bound

For I/O bound async/await syntax should be used. TPL should not be used for this. async methods does not spawns new thread to hand le I/O work asynchronously.

For CPU bound operations TPL should be used (Task.Run). This spawns new thread. Performance testing should be done to check if overhead of new thread and context switching is not greater than actual work to be done.

• software often waits for some I/O operation to complete (file operation, network call, database query etc.)
• we can use this time for something productive instead to wait for data to be available or I/O operation to be completed
• with asynchronous programming user can work in the meantime
• not waiting for I/O operations synchronously enhances user experience

Of course this problem is much more complex. Modern software operates on much more different PC architecture than 20 years ago. Nowadays software must be asynchronous to appear more user friendly and to made better use of modern multi CPU architecture. Right now complex, professional software uses multiple processes, threads on multiple CPUs (CPU you buy is not really *single* CPU) or even utilize GPU for more complex computations (like i.e. video editing software). Before that we mostly had single threaded desktop applications that had ‘please wait’ or ’loading’ pop ups. Right now this is song of the past really and to achieve better User Interfaces that allow to edit tag of your post without changing whole post. With mobile devices on the rise and sometimes lousy cellular network those kind of designs would not be sensible or sometimes impossible to implement. Did you ever happened to reenter some chunk of data into some software because you lost it? Maybe network was down? Or you hit back button by mistake? Right now it belongs to past mostly. All of those would be hard to do with synchronous operations. Right now people are bit spoiled and they tend to leave the page/application if it appears to be slow and not every company can sell ‘one-in-the-market-necessary-for-your-work-software’ that you will be forced to use. And this is why we have asynchronous operations and this is why we have asynchronous programming model that allows us to program such operations.

First things first - Why?

First of all I do not like how creating of views and navigation works in Xamarin. There is much boilerplate needed to just navigate from one page to another. Typically like in Xamarin documentation we have to obtain INavigation interface instance, create instance of a new page, create instance of view model and all dependencies it requires. When you page do not require view model things are real easy and Xamarin sample is just enough.

Web project often requires to push data to clients as fast as possible, whenever it is necessary without waiting for client request. It is perfect for website with real time communication between users, like with online communicators for example. Or document collaboration tools. Or maybe system status updates on long running calculation/tasks performed by server. In every case two way communication mechanism is ideal.