是锁定对布尔的访问权限还是过度杀伤 [英] Is locking access to a bool required or is it Overkill
问题描述
我有一个主要设计为POCO类的类，其中各种线程和任务都可以读取其值，只有其他类偶尔会更新这些值.对于ReaderWriterLockSlim，这似乎是一个理想的方案.
I have a class that is designed primarily as a POCO class, with various Threads and Tasks could read its values, and only others only occasionally updating these values. This seems to be an ideal scenario for ReaderWriterLockSlim.
问题是，在类中，如果该属性需要是线程安全的，如果该属性是布尔型的，那是不是太过分了?如果是int会怎样?日期时间?
The question is, in the class, if the property that needs to be thread-safe, if the property is a bool, is that overkill? what happens if it is an int? DateTime?
public class MyClass
{
private bool _theValue = false;
private ReaderWriterLockSlim _theValueLock = new ReaderWriterLockSlim();
public bool TheValue
{
get
{
bool returnVal = false;
try
{
_theValueLock.EnterReadLock();
returnVal = _theValue;
}
finally
{ _theValueLock.ExitReadLock(); }
return returnVal;
}
set
{
try
{
_theValueLock.EnterWriteLock();
_theValue = value;
}
finally
{ _theValueLock.ExitWriteLock(); }
}
}
}
所有这些代码是否都是多余的，而且简单...
Is all this code overkill, and a simple...
public bool TheValue { get; set; }
...足够吗? 因为类型是布尔型，所以安全吗?如果是这样，什么时候变得不安全? 字节?诠释?日期时间?
...would be sufficient? Because the Type is bool, is it safe? if so, when does it become not safe? byte? int? DateTime?
编辑
我的基本体系结构是具有此类存储状态.也许有一个服务负责对此类进行写操作.所有其他类都可以基于此状态数据读取并执行其逻辑.我将尽力确保所有数据都是一致的，但是如下所述，我主要关心的是数据的原子性和碎片性.
edit
My basic architecture is to have this class store state. Maybe have one service in charge of doing the writes to this class. All the other classes can read and perform their logic based on this state data. I will do my best to make sure all data is consistent, but as stated below, my main concern was the atomicity and splinching of data.
结论
感谢每个人的回应，所有这些都很有价值.我主要关心的是写入/读取的原子性(即担心碎片).对于.NET平台，如果所讨论的变量是小于4个字节的内置值类型，则读写是原子的(例如short和int很好，long和double则不是).
Conclusion
Thanks everyone for their response, all were valuable. My main concern was of atomicity of the writes/reads (i.e. worried about splinching). For the .NET platform, if the variable in question is a built-in value type that is less than 4 bytes, then the read and write is atomic (ex. short and int are fine, long and double are not).
推荐答案
您有一些选择.
- 什么都不做.
- 使类不可变.
- 使用普通的
lock. - 将字段标记为
volatile. - 使用
Interlocked组方法.
- Do nothing.
- Make the class immutable.
- Use a plain old
lock. - Mark the fields as
volatile. - Use the
Interlockedset of methods.
由于可以保证对bool的读写是原子的，因此您可能不需要执行任何操作.这在很大程度上取决于类使用方式的性质.原子性不等于线程安全.这只是它的一个方面.
Since reads and writes to a bool are guaranteed to be atomic then you may not need to do anything. This will very much depend on the nature of the way your class is going to be used. Atomicity does not equal thread-safety. It is only one aspect of it.
理想的解决方案是使您的类不可变.不可变类通常是线程安全的，因为它们不能被其他线程修改(或完全不能修改).有时候这只是不可行.
The ideal solution is to make your class immutable. Immutable classes are generally thread-safe because they cannot be modified by other threads (or at all for that matter). Sometimes this just is not feasible though.
我在列表上的下一个偏好是普通的lock.获取和发布的开销非常小.实际上，我认为您会发现lock在大多数情况下会胜过ReaderWriterLockSlim，尤其是当您正在做的只是读/写变量时.我自己的测试表明，RWLS的开销比lock慢5倍.因此，除非读操作异常长并且它们的数量大大超过写操作，否则RWLS将无济于事.
My next preference on the list is a plain old lock. The overhead of acquiring and releasing is very minimal. In fact, I think you will find that a lock will beat out a ReaderWriterLockSlim in most situations especially if all you are doing is reading/writing a variable. My own personal tests indicate that the overhead of RWLS is about 5x slower than a lock. So unless the read operations are unusually long and that they significantly outnumber write operations then RWLS will not help.
如果您担心锁开销，则务必将字段标记为volatile.只需记住volatile并不是解决所有并发问题的灵丹妙药.不能替代lock.
If you are concerned about lock overhead then by all means mark the fields as volatile. Just remember that volatile is not a magic bullet that solves all concurrency issues. It is not intended as a replacement for lock.
这篇关于是锁定对布尔的访问权限还是过度杀伤的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
