主页 / 问题 / 1580858
Accepted
Web FR
Asked:2024-05-20 00:49:13 +0800 CST2024-05-20 00:49:13 +0800 CST

这种情况下线程会死锁吗？

  • 772

如果我不赌lock接收，但我赌lock改变价值，在这种情况下是否可能出现死锁，或者我错了？lock在多线程情况下，您应该始终押注于 get 和 change 吗？

public class MyClass
{
    private object _lock = new object();

    private string _property;

    public string Property
    {
        get
        {
            // Получение без блокировки
            return _property;
        }
        set
        {
            lock (_lock)
            {
                // Изменение с блокировкой
                _property = value;
            }
        }
    }
}
c#

1 个回答

  1. Best Answer

    对于集合的线程安全修改，有线程安全集合。

    但假设我们不是在谈论这个，而是在谈论一个财产。正如他们在评论中所说，引用类型的赋值是原子的，并且类型string是不可变的，因此lock原则上不需要这里。

    但是我们想象一下，属性改变操作不是线程安全的，那么这里就有一个错误，你不能通过lock仅仅将其放在一个setter中来实现线程安全，因为如果写入不是线程安全的，那么有可能是不安全的读取将发生在写入的中间。

    因此，吸气剂也必须被锁定。

    public string Property
{
    get
    {
        lock (_lock)
        {
            // небезопасное чтение
        }
    }
    set
    {
        lock (_lock)
        {
            // небезопасная запись
        }
    }
}

    您正确地怀疑，当属性未发生更改时，您可以读取多线程，而不会阻塞线程本身。为此有一个读-写-锁设计模式。他表示，虽然没有记录，但任意数量的线程都可以读取数据，而当需要写入时，则需要停止所有读取，一次只写入一个。

    private readonly ReaderWriterLockSlim _lock = new();

public string Property
{
    get
    {
        _lock.EnterReadLock();
        try
        {
            // небезопасное чтение
        }
        finally
        {
            _lock.ExitReadLock();
        }
    }
    set
    {
        _lock.EnterWriteLock();
        try
        {
            // небезопасная запись
        }
        finally
        {
            _lock.ExitWriteLock();
        }
    }
}

    这样的话，当没有写的时候，就根本不会有读锁。不言而喻，如果保证读/写操作永远不会抛出异常，那么try-finally就不需要将其包装起来。

    • 1

相关问题