GorillasPaw's questions

Tenho uma variável de instância ou propriedade chamada Settingque é compartilhada entre threads.
Uma nova instância ocasionalmente será atribuída a essa variável por outras threads.
O método que usa Settingcopiará a referência antes de funcionar, e não há problema em usar a antiga Settingse ela estiver sendo atualizada quando o trabalho estiver prestes a começar, então o bloqueio não é necessário.

A leitura e a escrita únicas do tipo de referência são atômicas em C#, mas instruções compostas como var foo = new Foo()essa não são atômicas e podem ser reordenadas.
Este problema é bem ilustrado no bloqueio de dupla verificação. https://medium.com/@wangberlin2000/why-volatile-is-essential-in-double-checked-locking-singleton-0ba2906623fe
O link foi escrito em Java, mas o mesmo se aplica a C#.

https://csharpindepth.com/Articles/Singleton
Adicionado também o link para C#. Confira a "Terceira versão - tentativa de segurança de thread usando bloqueio de verificação dupla".

Gostaria de saber se é possível ler o Settingquando seu endereço de memória é alocado, mas a inicialização do objectnão é concluída.

O código de exemplo tem 3 Settingvariáveis ​​de membro de instância, propertye virtual propertyfunções que atualizam o Setting. É para fins de demonstração e o código real tem apenas uma Settinge uma função.

1. É UpdateMemberAsyncseguro usar, já que o conteúdo GetSettingAsyncnão pode vazar antes ou depois da awaitreordenação da memória?
2. Não é UpdateMemberByInlinableseguro usar porque GetSettingpode ser incorporado em vez de retornar o inicializado object?
3. É UpdateVirtualMemberseguro usar porque virtual propertynão pode ser embutido?
4. É UpdateMemberByNonInlinableseguro usar porque Apinão pode ser embutido?
5. É UpdateMemberUsingBarrierseguro usar?
6. Há algo que estou esquecendo além dos exemplos fornecidos?

Adicionado o link fornecido por Peter Cordes para aqueles que buscam informações mais detalhadas. https://preshing.com/20120612/an-introduction-to-lock-free-programming/

public class Service
{
    public Setting Setting = new();
    public Setting SettingProperty { get; set; } = new();
    public virtual Setting SettingVirtualProperty { get; set; } = new();

    // Called by other threads.
    public async Task StartAsync()
    {
        // It doesn't have to be the most recent value.
        var setting = Setting;

        await Foo(setting);
        await Bar(setting);
    }

    // Api is a class with a non-virtual or sealed function.
    public void UpdateMemberByInlinable(Api api)
    {
        Setting = api.GetSetting();

        // Inlined as below.
        var t = new Setting();

        Setting = ptrT;
        // or
        SettingProperty.BackingField = ptrT;

        // Set members of t after assigning the ptr.
    }

    // Api can be anything.
    public async Task UpdateMemberAsync(Api api)
    {
        Setting = await api.GetSettingAsync();
        // or
        SettingProperty = await api.GetSettingAsync();
        // or
        SettingVirtualProperty = await api.GetSettingAsync();
    }

    // Api can be anything.
    public void UpdateVirtualMember(Api api)
    {
        SettingVirtualProperty = api.GetSetting();
    }

    // Api is an interface or a class with a non-sealed virtual function.
    public void UpdateMemberByNonInlinable(Api api)
    {
        Setting = api.GetSetting();
        // or
        SettingProperty = api.GetSetting();
    }

    // Api can be anything.
    public void UpdateMemberUsingBarrier(Api api)
    {
        var setting = api.GetSetting();

        Thread.MemoryBarrier();

        Setting = setting;
        // or
        SettingProperty = setting;
    }
}

DoAsync, ConnectFtpAsync, ConnectDbAsynctudo funciona no projeto Console quando o número de tarefas excede o limite do semáforo.
No entanto ConnectFtpAsynce ConnectDbAsyncexceto DoAsyncfazem com que o projeto WPF congele quando o número de tarefas excede o limite do semáforo.

ButtonPressedAsync()qual é a chamada mais externa não usa o ConfigureAwait(false)e ConfigureAwait(false)usado na chamada interna não deve importar.

Remover o ConfigureAwait(false)from inner calls não resolveu o problema.
Remover o semáforo ou não exceder o limite do semáforo resolveu o problema.

FluentFTP e Oracle são usados ​​para o código fornecido.
3 exemplos são testados separadamente.

1. Por que ConnectFtpAsynccongelar ConnectDbAsyncum projeto WPF?
2. Por que DoAsynco projeto WPF não congela?

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        await ButtonPressedAsync();
    }
    
    private static async Task ButtonPressedAsync()
    {
        try
        {
            var connectionLimit = 4;
            var smph = new Semaphore(connectionLimit, connectionLimit);
            var tasks = new List<Task>();
    
            for (var i = 0; i < connectionLimit + 1; ++i)
                tasks.Add(DoAsync(smph));
    
            //for (var i = 0; i < connectionLimit + 1; ++i)
            //    tasks.Add(ConnectFtpAsync(smph));
    
            //for (var i = 0; i < connectionLimit + 1; ++i)
            //    tasks.Add(ConnectDbAsync(smph));
    
            await Task.WhenAll(tasks).ConfigureAwait(false);
        }
        catch (Exception ex)
        {
            ;
        }
    }
    
    private static async Task DoAsync(Semaphore smph)
    {
        smph.WaitOne();
    
        await Task.Delay(500).ConfigureAwait(false);
    
        smph.Release();
    }
    
    private static async Task ConnectFtpAsync(Semaphore smph)
    {
        smph.WaitOne();
    
        var ftpConnection = new AsyncFtpClient(
            host: "ip",
            port: 21,
            user: "id",
            pass: "pswd");
    
        await ftpConnection.Connect().ConfigureAwait(false);
    
        smph.Release();
    }
    
    private static async Task ConnectDbAsync(Semaphore smph)
    {
        smph.WaitOne();
    
        var credential = "credential";
        using var dbConnection = new OracleConnection(credential);
        await dbConnection.OpenAsync().ConfigureAwait(false);
        await dbConnection.CloseAsync().ConfigureAwait(false);
    
        smph.Release();
    }

Quando eu descomento await Task.Delay(1_000);, foo.DoAsyncwithin Task.Runé Task.CompletedTaskporque ele espera por Task.Runoverhead. Então ele roda normalmente.

Quando eu comento await Task.Delay(1_000);, foo.DoAsyncdentro do Task.Run é ele mesmo. Após o primeiro hit do breakpoint2 no modo de depuração, ele não atinge mais o breakpoint2.

internal class Foo
{
    public Task DoAsync { get; set; }

    public void Recursive()
    {
        // Breakpoint1
        Recursive();
    }
}

var foo = new Foo() { DoAsync = Task.CompletedTask };

//foo.Recursive();

Console.WriteLine($"Outer ThreadId: {Environment.CurrentManagedThreadId}");

var task = Task.Run(async () =>
{
    Console.WriteLine($"Inner ThreadId: {Environment.CurrentManagedThreadId}");
    // Breakpoint2
    await foo.DoAsync;
    Console.WriteLine("""
        ******
        ******
        ******
        done
        ******
        ******
        ******
        """);
});

await Task.Delay(1_000);

foo.DoAsync = task;

await foo.DoAsync;

Eu esperava que ele atingisse o breakpoint2 infinitamente, assim como foo.Recursiveatingiria o breakpoint1 infinitamente até que ele travasse. Para onde vai o fluxo de controle após o acerto inicial no breakpoint2?