Sync over async in .NET is always bad and there is no better advice than just to avoid it. What does “Sync over async” mean exactly? It happens if you synchronously wait on an asynchronous operation result with the help of .Result, .Wait or similar. Why is it bad? First of all, it blocks (wastes) one thread to wait on a result – which may lead to threads starvation. But even worse, it may deadlock your operation and (sometimes) the whole application.

Probably you’ve heard all that previously. I just wanted to present a picture, “worth a thousand words“, to explain why does it happen.

synchronizationcontext_winforms_nestedsyncThere is a concept of SynchronizationContext in .NET – an abstraction that knows how/where schedule a work item (like an async/await continuation). When you await something, SynchronizationContext is being captured. And when continuation is going to be run – we use SynchronizationContext to run the continuation “somewhere”. SynchronizationContext implementation may be different in various scenarios (console, UI, web, mobile applications), because there are various needs to “synchronize” work items. The main example is a GUI-based application. When we start an asynchronous operation on the UI thread, we expect its continuations will “return” to the same thread.

But, if we .Result that operation, the main UI thread is blocked waiting on the result, so it is not able to process anything (including mouse/keyboard events). So there is no way continuation (that would set the result) may run, thus we endlessly wait for the result – deadlock.

synchronizationcontext_winforms_configureawait

That’s why ConfigureAwait helps – it allows to say “I don’t care about scheduling continuation to the original (captured) context“. Thanks to that asynchronous operation continuation is scheduled to a different thread (thread pool’s) and sets the result with no problem. This resumes the main UI thread, and there is no deadlock.

That was just two simple drawings. If you’d like to know more, refer to a great ConfigureAwait FAQ by Stephen Toub.

Again, all this is just a work for a much bigger project, which is awesome Async Expert on-line course about asynchronous and concurrent programming in .NET. If you found it interesting, stay tuned by subscribing to the newsletter on the above-mentioned page!

It is said that picture is worth a thousand words, and I agree. That’s why I like preparing technical drawings to explain various concepts. So, here it is – a short story of how async/await works in .NET.

thereisnothread

The main power behind async/await is that while we “await” on an ongoing I/O operation, the calling thread may be released for doing other work. And this provides a great thread re-usability. Thus, better scalability – much smaller number of threads is able to handle the same amount of operations comparing to asynchronous/waiting approach.

The main role here plays so-called overlapped I/O (in case of Windows) which allows to asynchronously delegate the I/O operation to the operating system, and only after completion the provided callback will notify us about the result. The main workforce here is so-called I/O completion port (IOCP).Continue reading

poh01

In the upcoming .NET 5 a very interesting change is added to the GC – a dedicated Pinned Object Heap, a very new type of the managed heap segment (as we have Small and Large Object Heaps so far). Pinning has its own costs, because it introduces fragmentation (and in general complicates object compaction a lot). We are used to have some good practices about it, like “pin only for…:

  • a very short time” so, the GC will not bother – to reduce probability that the GC happens while many objects were pinned. That’s a scenario to use fixed keyword, which is in fact only a very lightweight way of flagging particular local variable as a pinned reference. As long as GC does not happen, there is no additional overhead.
  • a very long time”, so the GC will promote those objects to generation 2 – as gen2 GCs should be not so common, the impact will be minimized also. That’s a scenario to use GCHandle of type Pinned, which is a little bigger overhead because we need to allocate/free handle.

However, even if applied, those rules will produce some fragmentation, depending how much you pin, for how long, what’s the resulting layout of the pinned objects in memory and many other, intermittent conditions.

So, in the end, it would be perfect just to get rid of pinned objects and move them to a different place than SOH/LOH. This separate place would be simply ignored, by the GC design, when considering heap compaction so we will get pinning behaviour out of the box.Continue reading

Mobius Overview

.NET application is “just” a piece of CIL bytecode to be executed by the .NET runtime. And .NET runtime is “just” a program that is able to perform this task. It happens that currently .NET Framework/.NET Core runtimes are written in C++. I am also fully aware of CoreRT that was .NET runtime with many parts rewritten to C# (like type system) but still, crucial parts (including JIT compiler and the GC) were left written in C++.

But what if we write .NET runtime as… .NET application? Is is possible at all? I mean, literally no native/C++ code, everything running as .NET Core application written in C#? Does this sound like kind of inception and infinite recursion? It would require running one .NET runtime on the top of another .NET runtime, right?

I decided to check it out and that’s how Mobius runtime idea has been coined! Yeah, I know it sound strange and I do not expect it will be anything close to production ready thingy in the nearest century. I am fully aware of the amount of code needed to be written to make full .NET runtime. However, I found it interesting to validate such idea and I find it small usages as well. Imagine a NuGet package with the separate runtime that you can add to your application 😉

Continue reading

GC posters

In short words, I’ve prepared two posters about .NET memory management. They provide a comprehensive summary of “what’s inside .NET GC”, based on .NET Core (although almost all information is relevant also for .NET Framework).

The first shows a static point of view – how memory is organized into segments, generations, what are the roots and etc.:

Poster I

The second shows a dynamic point of view – how GC threads are working and what GC modes are available:

Poster II

 

You can download them for FREE in vector PDF format from my https://prodotnetmemory.com site. Take it and print it!

 

 

bothgamesbanner_white

2 Developers from Poland join forces to publish their IT-related card games: from Devs to Devs – OutOfMemory and IT Startup!

Each of us already has a published book and now we want to share some knowledge with fun games! Remember all the original 151 Pokemon names? How about playing a game that lets you remember something useful: like what technologies are beneficial to learn to be a better Developer! One of the games is already published in Poland and sold over 3k copies (so we how already some publishing know how). Now we want to start a company and publish 2 of our IT related card games worldwide in English.

Have fun while playing our print and play prototypes!

We plan to publish the games as one company on Kicktarter in Q1 2020.

Continue reading

prototype07

So…after quite a serious thing which was writing Pro .NET Memory Management book, I’ve decided to experiment with a little pet project for having some more fun. I have quite a few very interesting ideas going on in my head. Yet, I needed to choose one!

And that’s how an idea of OutOfMemory game prototype materialized! Ladies and gentleman, please meet the first in the world card game about .NET-based high performance and memory-aware programming. Sounds so nerdy, doesn’t it?! That’s by design and I like it! From developer to developers, with love 😉 It contains a huge amount of stuff related to programming, hardware architecture and… GC obviously! This is going to be a physical card game, not a computer or a mobile one.

The goal of the game is to build an application. You build it by playing on the table so-called Feature cards – the first player getting a given amount of Feature points wins!

prototype01

But each Feature has its cost! Each Feature card allocates Memory and consumes CPU Ticks. At the end of each player’s turn, you add an appropriate amount of Memory. If you hit a given limit – OutOfMemory occurs! CPU Ticks play also an important role in limiting possible actions in a turn.

In each turn, the player takes a single card from a deck. Or two, if she has an appropriate special card which is… Adam Sitnik‘s card (an example of a Hero card). Another example of .NET Hero card is Ben Adams – very powerful as it both reduces Memory and CPU Ticks, has a special ability (removes all the nasty Issues played against you by your opponents) and even adds a single Feature point (having Ben contributing to your app is a feature by itself)!

prototype02b

Guess who is on the other Hero cards?! Currently, I plan eight such cards!

Card(s) taken from the deck can be used immediately or kept at hand (but there is a limit of cards in hand, reflecting CPU cache my dear!)

There are various other types of cards. For example, there are Garbage Collection Action cards so if you are lucky enough (and plan to keep them in advance) you can clean your Memory periodically.

prototype03

A lot of cards help you to keep Features while reducing their Memory and/or Ticks costs, like Span<T> or Lock-free programming

prototype04

There are also nasty Bug and Issue cards that you can play against your opponents, removing their Feature points or making their app more allocating and slower!

prototype05b

Additionally, there are various Action cards that can be played to receive a short, single-turn benefit. Some influence only you, some a given opponent, and some all the players – like Black Friday cards that makes all Features double-allocating in the next turn (due to high volume traffic!).

prototype06

All this is in a very early prototype stage, requiring possibly quite a lot of rethinking. And a lot of balancing is required to create playable and enjoyable deck. Currently, my prototype consists of 80 cards.

prototype07

I am playing this game a lot with… myself, to balance the very first prototype. When ready, I plan to publish self-printable very rough version and I hope there will be .NET developers out there willing to try it out! With your feedback, we may create an amazing game!

Nevertheless, I would LOVE to start receiving your feedback RIGHT away! Do you like this idea? Do you have ideas of Hero, Bug, Issue, Fix and Feature cards?


If you are want to be informed about further work and the prototype, feel invited to subscribe at a dedicated page!


Note also that this initiative is a part of a bigger Dotnetos initiative – although currently only I am involved in the design of this game, most probably sooner or later all three Dotnetos will be somehow involved in it – I hope so!

Note. All graphics on cards and the cards itself are prototypes and do not reflect the final quality. Moreover, all cliparts were taken from Free Vectors via vecteezy.com.

gcbook

It’s been about half a year since my book has been published and people started to read it. Some even already finished! I thought it would be nice to gather all the reviews I’ve seen so far. There are not so many still – I was able to find 13 reviews on various sites. Still, big thank you for those who write them!

I must admit, I am very, very pleased with those opinions! There are almost no negatives! The greatest satisfaction is given by statements that someone felt a better programmer after reading it. Or applied it in practice immediately. Some reviews are quite comprehensive, some are pretty short. To help you in skimming all them, I’ve highlighted the most interesting (and positive!) parts of them. Negative parts are also highlighted – luckily there is so few of them!


review05 review11


 

Obviously, general statements about the book being very well-written or structured are also very pleasing! Hearing “amazing” about your work is awesome!

 


review10

review04


 

One of the nicest things is to hear that this book is a “must read” for every .NET developer!

 


review09


 

The same about hearing that it is “one of the best books about .NET” or the best book about this topic!

 


review08

review07

review12


 

And even two of those reviews are written by friends of mine, I know them well enough to be sure they are writing sincerely. If they did not like something, they’d write it honestly!

So after more than two years of writing, this is a kind of reward for me to read all this!

 


review02

review03


 

The very first review was kind of problematic because of Amazon’s formatting issue. Not my fault, unfortunately. But luckily reviewer revised his review after correspondence with the Amazon (AFAIK).

 


review06


 

So in summary – I am very pleased to hear that people like the approach taken by me in designing this book. I wanted it to be both very theoretical (a lot of deep-inside stuff and its theoretical basis) and very practical (presented Scenarios and Rules). And it seems it works!

 


 

review13

review01


 

Reviews presented here were taken from the following pages:

If you see another review elsewhere, or you’ve written one, please leave a comment!

And if you’ve read my book already, please write a review somewhere!

 

TL;DR – would be post-mortem finalization available thanks to phantom references useful in .NET? What is your opinion, especially based on your experience with the finalization of your use cases? Please, share your insights in comments!

Both JVM and CLR has the concept of finalizers which is a way of implicit (non-deterministic) cleanup – at some point after an object is recognized as no longer reachable (and thus, may be garbage collected) we may take an action specified by the finalizer – a special, dedicated method (i.e. Finalize in C#, finalize in Java). This is mostly used for the purpose of cleaning/releasing non-managed resources held by the object to be reclaimed (like OS-limited, and thus valuable, file or socket handles).

However, such form of finalization has its caveats (elaborated in detail below). That’s why in Java 9 finalize() method (and thus, finalization in general) has been deprecated, which is nicely explained in the documentation:

“Deprecated. The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks; there is no way to cancel finalization if it is no longer necessary; and no order is specified among calls to finalize methods of different objects. Furthermore, there are no guarantees regarding the timing of finalization. The finalize method might be called on a finalizable object only after an indefinite delay, if at all.”

Continue reading

As a part of my consultancy job, I have a pleasure to help various customers with problems that could be described collectively as GC-related (or memory-related in general). One day Tamir Dresher from Clarizen company (BTW, an author of Rx.NET in Action) contacted me with such an extremely interesting message (emphasis mine):

We are experiencing a phenomenon of GC duration of 15 minutes in our backend servers. (…) Do you think we can have a session with you and perhaps you’ll have ideas on how to find the root cause?

15 minutes! That’s an infinity! If we see something like this, one thought comes to mind – something really serious must be happening there! As nowadays most of such problems may be diagnosed remotely, after signing NDAs we could go straight into attacking the problem. Clarizen has provided a very well-prepared and concise summary of their architecture and current findings.Continue reading