If you dip your toes in AOT compilation you’ll have to be familiar with some concepts before.

Managed and unmanaged code

The .NET framework has multiple technologies (ASP.NET for web, WinForms for desktop, EF for ORM), including the Common Language Runtime, usually abbreviated to CLR - the .NET runtime.

A runtime, which is a programming language and framework agnostic term, it’s the environment responsible for basically executing your high-level code into low-level code (along with other features like memory management, type checking and exception handling). When writing C#, you won’t have to worry about memory allocation/deallocation, stack management, type safety, etc… however, these concepts still exist, and they’re managed by the runtime! This is called managed code.

When writing C/C++, you’ll have to worry about pretty much everything related to management - it’s an unmanaged code. The program compilation is just a binary that the OS loads into memory and starts.

This is the whole beauty of managed code. Instead of writing in beep-boop…

…you’ll write a little more in human.

At the end of the day, the runtime it’s simply (but not a simple) an engine that abstracts these managements that, when made manually, would commonly result in crashes. That’s why low-level languages have little, if any runtime.

Intermediate Language

One of the many .NET framework technologies are programming languages. Today, we have 3 of them: the popular and cool C#, F# and Visual Basic (old and uncool).

As every high-level language, they need to be translated into machine code. Instead of translating each of these high-level languages into binary code directly, each programming language compiler (note: not the runtime) translates the high-level code into an abstraction layer called Intermediate Language (IL) or sometimes called Common Intermediate Language (CIL).

The compiler of C#, for instance, can usually be found at C:\Windows\Microsoft.NET\Framework64\[version]\csc.exe.

This abstraction layer makes the runtime programming language agnostic. The only runtime domain is the Intermediate Language, independently from which language it was originally compiled.

Since the Intermediate Language it’s the only language to be translated into native code, there’s no need for each programming language compiler to adapt its source code for specific CPU architectures - the CLR does that job with the abstraction layer, the Intermediate Language.

Now, what’s AOT compilation?

AOT means Ahead-of-Time compilation and it is one of the multiple compilation strategies there are - each one of them having its own advantages and disadvantages.

When you publish a .NET Web API without any explicit compilation strategy, for instance, .NET will compile your application as Just-In-Time compilation, aka “JIT” compilation. That’s the default compilation strategy for most (if not all) .NET applications.

 dotnet publish -c Release -o /publish

In JIT compilation, the IL (or the JVM bytecode in Java) is translated into machine code at runtime - that means each chunk of IL code will be translated only when it is actually reached (note: JIT compilation will always use an intermediate language to translate it to machine code. If it would use a high-level language directly - like AOT does (we will get there) -, the cost of speed would be much higher because these intermediate languages will always be lower level).

Thus, high-level languages compilers such as the csc.exe will translate high-level code to Intermediate Language, a lower-level version of the code that makes it easier to translate it to machine code. Translating the IL to machine code is now the runtime role, not the compiler role. At runtime, you choose which compilation strategy you want for translating IL to machine code.

Important to remember that there are multiple CPU architectures out there and any set of instructions that you need to execute must be adapted for the CPU architecture the code it’s going to run. In .NET, this adaption is made in the runtime. That’s why you can run IL code in any CPU architecture since the host has the .NET runtime configured.

Now if JIT compiles bytecode into machine code on demand and uses the runtime to adapt the machine code for specific CPU architectures, AOT does it in a different way: like the name itself suggests, the compilation process is made ahead of time, which is during build-time rather than during run-time. That means IL is translated into machine code when you build your project for the first time. Thus, you must specify the CPU architecture up front, because the produced binary already contains instructions for that target (the app it’s mostly self-contained and does not require a JIT compiler at runtime now):

 dotnet publish -r win-x64 -c Release

AOT compilation in .NET

To build a .NET application using AOT, you’ll first have to enable it in the project file

<PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

and then build it with the specified CPU architecture as already shown above:

 dotnet publish -r win-x64 -c Release

When you build your application using AOT, .NET produces it as a self-contained app. Here, you can read some advantages and disadvantages about it and its limitations too.

Conclusion

As most things in computer science, each compilation strategy brings it’s own pros and cons. IMO you’d usually not worry about these things unless you’re working in a high-performance focused application - which was the case of the back-end challenge I mentioned!

I’d compare benchmarks between both compilation strategies but now I have a Defect to work on and a manager to please!

class MyCustomWorker : BackgroundService
{
    private const int RunAt = 1;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            if (DateTime.UtcNow.Day == RunAt && DateTime.UtcNow.Hour == RunAt)
            {
                await DoAsyncWork();
            }
        }
    }
}

Quando esse worker é injetado com AddHostedService<T>, qualquer outro worker injetado também com AddHostedService<T> não será mais executado - e isso se deve pela forma em que o runtime do .NET gerencia a inicialização desses workers.

Entender o motivo desse problema te força a entender um pouco mais sobre assincronicidade e sincronicidade, um conceito muito mais complexo do que se parece a primeira instância.

Threads

Na ciência da computação, a thread é a menor sequência de instruções programadas que podem ser gerenciadas independentemente por um scheduler, que normalmente faz parte do sistema operacional.

Fonte: Wikipedia

Ou seja, dentro de cada thread há um fluxo de código que você define. Tudo o que roda por um programa de computador é executado por pelo menos uma thread (e várias delas podem ser executadas ao mesmo tempo).

Quando se é usado um await Async(), a thread é liberada para o thread-pool se Async() for I/O bound (ou seja, um processo que não precise de uma thread, como por exemplo esperar o resultado de um banco de dados ou de uma requisição HTTP).

Isso significa que, enquanto um fluxo que não está utilizando nenhuma thread é realizado (e eu preciso esperar o resultado dele), eu devolvo a thread que eu estava usando até então para o thread-pool - e lá algum processo pode utilizar essa thread para um processo CPU bound (ou seja, um processo que de fato precise de uma thread da CPU).

Inicialização do BackgroundService pelo runtime do .NET Core

 await AAsync();
 await BAsync();
 await CAsync();

Ao usar o await, o código é executado de forma sequencial, ou seja, BAsync() só será executado quando AAsync() for finalizado e CAsync() só será executado quando BAsync() for finalizado. O ganho, nesse caso, é você liberar a thread para o thread-pool para outros processos utilizá-lo enquanto você espera pela resposta de cada método.

Dito isso,

AAsync();
BAsync();
CAsync();

não usar o await executará AAsync(), BAsync() e CAsync() de forma assíncrona, mesmo que na definição desses métodos hajam operações await.

Mas AAsync() pode travar para sempre mesmo sem um await em sua chamada, e é exatamente isso que acontece com o BackgroundService.

Na definição do construtor do StartyAsync() do runtime do .NET, o método ExecuteAsync() - que é o nosso worker - é chamado sem um await.

Como resultado, o runtime irá iniciar a execução do worker e, sem esperar pelo resultado dele, retornará um Task.CompletedTask, finalizando assim a execução de StartAsync(). Isso faz sentido, pois a ideia não é o runtime esperar pelo término de cada worker (afinal é um trabalho em segundo plano), mas sim apenas inicializá-los.

Agora, importante entender como o StartAsync() é chamado pelo runtime.

Na documentação da Microsoft, é especificado que o StartAsync() é chamado de forma sequencial, ou seja, com o uso do await. Simplificando, o runtime faz o equivalente de:

await myCustomWorker.StartAsync();
await smsWorker.StartAsync(); 
await cleanRecordsWorker.StartAsync();

Dado a definição de StartAsync(), sabemos que o runtime vai apenas iniciar cada worker e, sem esperar por seu resultado, irá nos retornar o Task.CompletedTask - fazendo assim com que o await myCustomWorker.StartAsync() seja finalizado, depois await smsWorker.StartAsync() e depois await cleanRecordsWorker.StartAsync(), tudo de forma basicamente instantânea.

No entanto, se nossos workers não liberarem a thread instantaneamente (e a thread é liberada ao fazer o uso do await, como explicado), a linha

// Store the task we're executing
_executingTask = ExecuteAsync(_stoppingCts.Token);

do construtor de StartAsync() ficará travada esperando a liberação da thread. Ela está “esperando”, mas sem o await. A thread ainda não foi liberada para a continuação do fluxo do construtor (e como consequência os outros workers não são inicializados).

Na definição dada de MyCustomWorker, nenhum await é executado - logo, nenhuma thread é liberada e consequentemente a chamada de ExecuteAsync() irá travar. Com a chamada de ExecuteAsync() travada, o runtime não vai finalizar a execução de await myCustomWorker.StartAsync() (porque estamos esperando o término com o await) e nenhum outro worker será executado.

Esse design faz sentido pois se nenhum await é utilizado (e o await é utilizado para operações I/O bound), uma operação CPU bound está sendo executada - e como sabemos, uma operação CPU bound precisa de… threads de CPU.

Na prática, se o worker inicia com uma lógica síncrona que demora 10 segundos e só depois um await é executado, a chamada de ExecuteAsync() no construtor de StartAsync() só será liberada depois dos 10 segundos.

class MyCustomWorker : BackgroundService
{
    private const int RunAt = 1;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        MetodoCPUBoundQueDemora10Segundos(); // aqui o construtor tá travado (pois estamos usando threads)
        var dados = await BuscaDadosNoBancoAsync(); // aqui a thread é liberada e o construtor continua seu fluxo

        while (!stoppingToken.IsCancellationRequested)
        {
            if (DateTime.UtcNow.Day == RunAt && DateTime.UtcNow.Hour == RunAt)
            {
                await DoAsyncWork();
            }
        }
    }
}

Um loop, como é o caso do MyCustomWorker na linha while (!stoppingToken.IsCancellationRequested), também é uma operação CPU bound, ou seja, um worker que inicia com um looping também irá travar a chamada de ExecuteAsync() - mas dessa vez irá travar pra sempre!

A solução

Se uma operação CPU bound é executada no início do nosso worker, não queremos que o runtime espere o término dessa operação. Ele pode continuar o seu fluxo e inicializar os outros workers e, depois, essa operação CPU bound arranja uma outra thread no thread-pool. Pra liberar a thread sem necessariamente awaitar algo, basta usar await Task.Yield():

class MyCustomWorker : BackgroundService
{
    private const int RunAt = 1;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await Task.Yield();

        while (!stoppingToken.IsCancellationRequested)
        {
            if (DateTime.UtcNow.Day == RunAt && DateTime.UtcNow.Hour == RunAt)
            {
                await DoAsyncWork();
            }
        }
    }
}

await Task.Delay(1) também funciona pelo fato de liberarmos a thread no await. Task.Yield() é a forma formal de se fazer isso.

Com isso, qualquer código lento ou qualquer loop não irá travar a execução de ExecuteAsync() e todos os outros workers serão inicializados corretamente.

Why Bananas are OP.

Yesterday I was hanging out with two friends of mine when I needed to eat something before college. I generally buy some junkie foods and don’t care at all, but these two friends are healthy and happy people. One of them suggested to buy two Bananas and an apple (note that it’s ‘apple’, not ‘Apple’, because apple isn’t a divinity for me - not a diss for Apple, the company). Of course that I laughed at them at first, but then I started to really take this idea into account. Was when I, for the first time after I don’t know how many years, went to buy a Banana. Now, a few things to consider.

Bananas are really cheap.

That was the first thing that I noticed when I bought them. 2 Bananas did cost 0,98 brazilian bucks! One of my friends also said that it was too expansive, but who cares? 0,98 for TWO beautiful and colorful Bananas. I took them. Then I bought the apple, that cost me 2,95 bucks. And that’s it, everything worked fine.

Bananas design are genius.

Stop and think about it. A natural fruit have such a genius design. You look at a Banana and you already know how it works, you know what you’re supposed to do.

First, the Banana peel protect the fruit. Besides protecting it, the peel contains NUTRIENTS!!! There is literally no downside - at least as far as I know. I never ate the peel and I don’t know if I want to, but just the fact that Banana’s shield contains nutrients is an incredible thing. Second, the shape of a peeled Banana is satisfying to look at. When you’re eating something beautiful, you naturally want more of that food. That’s the case of Bananas.

Bananas are tasty

Genuine question: Is there someone in this life that doesn’t like Bananas taste? Someone that says: “Oh, well, I don’t like the sweet of Bananas. I prefer Apples!”. Honestly, I don’t think so. Bananas taste are just incredible, everything is balanced. That means that you can eat something healthy and that is tasty. Again, another incredible point from Bananas.

Bananas can be used as fertilizer

Simply amazing. Can you understand that? You eat the Banana but you still got the peel. You don’t need to necessarily throw it away in a trash, you can just throw it around plants. There are better ways to use Banana peel as fertilizer, but this will not harm the environment. +10 points for Bananas.

Banana is synonymous of chimpanzees, the smarter animal before us.

Some haters may say that we “think that chimpanzees eat Bananas” because they are grown in tropical areas, where chimpanzees usually live. You can believe in that if you have an average IQ, but if you think more about it, you realize that chimpanzees eat Bananas (and are their preferred fruit) because they know everything that you’re reading. They know how OP Bananas are and know that they get advantage eating a fruit like that.

Why do you think that hippos aren’t smart as chimpanzees? The only accepted answer is because they don’t eat Bananas as chimpanzees do. Simple like that.

Bananas are healthy

Last but not least, Bananas are very healthy. It has high levels of potassium, which helps regulate water levels in the body. It is rich in vitamins, namely A, C, E and the B complex. It also has essential minerals such as calcium, zinc, magnesium, and more. How can something be good and healthy? OP.

Conclusion

Bananas are a kind of God-fruit. They have beautiful design, are tasty and healthy. I’m not trying to convice you to eat Bananas and being healthy, I’m just saying facts.

When we talk about decentralization the first thing we correlate is the currency that has been in hype for years: Bitcoin. Bitcoin is a virtual, decentralized currency that is distributed and stored on the Blockchain - the technology that enables decentralization.

A decentralized system is one that does not have a central entity/authority acting as an intermediary. The Brazilian Real, for example, is a centralized currency: the Brazilian Mint acts as the central authority and intermediary; it defines how many banknotes and coins will be made. They are the ones in total control of the currency.

Bitcoin has a finite number of copies and all its transactions are public and unchangeable. Because the network is run by several users (the miners), this makes it decentralized.

The theory of a decentralized monetary system is simple, as you can see. We can simply think of a currency that has all its transactions public, has no authorities acting as intermediaries, and somehow cannot have its transaction history changed. Before the invention of the Blockchain (which came along with the invention of Bitcoin, by Satoshi Nakamoto) we never had the ability to implement such a system in a technical way, that is, implementing and popularizing it was always the problem.

Why create a decentralized monetary system?

Bitcoin was created by Satoshi Nakamoto (a pseudonym, since nobody knows his real identity) who, we all believe, did not support the idea of banks having access to all our transactions. Knowing this, the fact that we have a monetary system where there are no bank interventions is a remarkable advantage. Consequently, we have a decrease in fraud and/or manipulation.

A decentralized system, however, is commonly used for crimes. Since there is no one acting as an intermediary, remaining anonymous within the network is extremely simple; this is why criminals demand cryptocurrencies as a form of payment in most cases.

As a consequence of the anonymity, money laundering with cryptocurrencies has been used many times.

Decentralized system in practice

Imagine that you, me, and Joãozinho want to create a system similar to Bitcoin. All the monetary transactions we make with each other are stored on a sheet of paper. At the end of each month, we pay what we owe each other.

This is, in a nutshell, how a Blockchain works with cryptocurrencies: It stores all transactions in public form. If we were all honest, this system would work perfectly: nobody would change the value of the transactions, the sender or the receiver of the transactions. But in this paper scenario, nothing prevents someone from taking a pen and adding a few extra zeros to Joãozinho’s transaction.

Two things prevent the data in a Blockchain from being altered: its architecture, which will be commented on, and mining.

Cryptocurrency Mining

All transactions on a Blockchain need to be validated. This means that if Bob transfers 1 BTC to Alice, the amount will not automatically be transferred to his wallet, because first it needs to be validated. The act of validating a transaction is what we call mining.

Cryptocurrency mining is done by miners. Miners are nothing more than users who place their computing power (hardware) on the Blockchain network. The more computing power, the faster the transactions will be validated.

Validating a transaction is validating a purposefully complex mathematical calculation (in the case of the Proof of Work validation method - protocol used by Bitcoin). Miners solve mathematical calculations that purposefully require a lot of computing power. This process, depending on the Blockchain, can take seconds, minutes, or even hours. When this mathematical calculation is completed by a miner, a new block in the chain (the data of a transaction) will be added and the miner will be rewarded for his computational effort. Only at that point will a transaction be completed.

In other words, the role of miners is simply to put their computing power to solve mathematical calculations. When these calculations are solved, the block is validated and can be added to the chain.

The purpose of these calculations being purposely complex is directly linked to the architecture of the Blockchain that must first be understood.

Technically speaking, how does a Blockchain allow a system to be decentralized?

Imagine the Blockchain as the name implies: a chain of blocks connected by a chain.

Its architecture consists of “blocks” that have the reference of the previous block (chain) - like an interconnected chain - and each block has a stored information (a monetary transaction, for example). Having a reference to the previous block is what makes the Blockchain immutable, i.e., almost impossible to have its information changed.

Each block contains the following information:

• Amount: the amount of Bitcoins to be transferred;

• Sender: the hash of the block that is sending the Bitcoins (sender);

• Recipient: the hash of the block that is receiving the Bitcoins;

• Hash: the hash of the current block;

• Previous hash: the hash of the previous block.

The first block (Block 1) is called the genesis block. As you can see, it has one less property: the previous hash. This is because this is the first record in the Blockchain, i.e., there is no previous block to store the hash. It is important to remember that the hash of each block is defined by the information it contains. If a piece of information changes, the hash of the block will automatically change as well.

The picture gives an example of a Blockchain with three transactions recorded. The first transaction was 10 Bitcoins for address 345, the second was 1 Bitcoin for address 678, and the last transaction was 20 Bitcoins for address 91011.

Now imagine that someone modifies the properties of Block 1. Instead of 10 Bitcoins sent to hash 345, 20 Bitcoins are reported in the record. Unlike the sheet of paper example, this would cause problems due to the previous hash property that all blocks - with the exception of the genesis block - have.

Since one value of Block 1 (amount) has changed (from 10 to 20), the hash of the block will automatically change (from 123 - its original value). When the hash of this block changes, the previous hash property of the next block will also change. If this property changes, the original hash of this block will also change, and so on, causing a domino effect throughout the Blockchain. Automatically, the value of all blocks in the chain will change, and consequently, will have to be validated again.

Role of the miners

Since all the blocks in the chain will change if a single value is modified, the entire chain will have to be validated again. As already mentioned, mining a single block in a chain can be a very time consuming task.

By default, the blockchain that will be considered true will be the one with the most blocks validated. Because of this, you would not be able to change the values of the records by yourself because you would need to validate all the blocks in the Blockchain again. Doing this successfully means having more computing power than all the miners in the entire world - something that is unlikely. In 2022, there are about 1,000,000 Bitcoin miners around the world. They all work non-stop to validate new blocks on the network. Since they all work around the clock validating blocks in a single chain, being able to change records and validate more blocks than they do is unlikely because you are at a computational power disadvantage.

The only possible way to successfully change the values of a blockchain is to validate more blocks than all 1,000,000 miners combined - which is physically almost impossible, since you would need to have a computational power as high as all the computational power of all the miners working in the chain.

In other words, the more miners working to validate blocks in the chain, the more computational power is required for a single person to change the records.

This is a very interesting approach because successfully changing records depends on something physical (hardware), not digital.

The only way to change the records of a Blockchain - 51% Attack

51% Attack is a type of attack where one person or a group of people have more computing power (51% +) than the power of all the miners together working on the chain. In this scenario, the individual could change one value in the chain and validate the entire chain again. Since he has a higher computational power than all the other miners combined, he could continue validating the chain and consequently validate more blocks; which would make the chain the largest in the blockchain. If this happened, it would be considered the true chain even though it contains changed data.

This means that you could only successfully alter the records of a blockchain if you mastered at least 51% of the computing power working on the chain.

Energy consumption for transaction validation

In May 2021, Elon Musk - one of today’s biggest cryptocurrency influencers - tweeted about Tesla, his electric vehicle company, no longer accepting Bitcoin as a form of payment.

According to him, the rapid growth in the use of fossil fuels for mining the cryptocurrency worries him.

Bitcoin started to have a lot of visibility a few years ago, which made many people enter the mining market. Consequently, the demand for power and GPUs have increased dramatically, which directly influences their markets.

It is estimated that to validate a single Bitcoin transaction, about 2100 kWh of energy is used, which is roughly what an average American household consumes in 75 days.

All the rising energy prices have caused miners to opt for cheaper alternatives for mining, such as the fossil fuel that was commented on by Elon Musk. Because of the competition, miners are looking for cheaper options, but they are the most polluting, thus directly affecting the environment.

As a solution to this problem, new validation mechanisms are already being developed and even used, as is the case of Proof-of-Stake, a mechanism that will be used by the Ethereum network and that does not depend on computing power for validations.

References

• https://pt.wikipedia.org/wiki/Blockchain
• https://ethereum.org/en/defi/
• https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
• https://bitcoin.org/bitcoin.pdf
• https://ethereum.org/669c9e2e2027310b6b3cdce6e1c52962/Ethereum_White_Paper_-_Buterin_2014.pdf

But now I’m using this template that does everything that I need: write about random things that comes to my mind.

I’m creating this blog because I want to leave my thoughts on some topics on the internet. I also like to talk about my personal projects.

As I’m still not a influencer with 1kk followers, I won’t be an active poster. For now, I’m just doing it for fun and because I like the way I explain things. I think I’m good at it.