互锁用于递增/模仿布尔值,这安全吗?
我只是想知道一位开发人员同事(现已离开)的这段代码是否可以,我认为他想避免加锁。这与仅使用直接锁之间有性能差异吗?
private long m_LayoutSuspended = 0;
public void SuspendLayout()
{
Interlocked.Exchange(ref m_LayoutSuspended, 1);
}
public void ResumeLayout()
{
Interlocked.Exchange(ref m_LayoutSuspended, 0);
}
public bool IsLayoutSuspended
{
get { return Interlocked.Read(ref m_LayoutSuspended) != 1; }
}
我在想这样的事情如果有锁会更容易吗?它确实会被多个线程使用,因此决定使用锁定/互锁。
I'm just wondering whether this code that a fellow developer (who has since left) is OK, I think he wanted to avoid putting a lock. Is there a performance difference between this and just using a straight forward lock?
private long m_LayoutSuspended = 0;
public void SuspendLayout()
{
Interlocked.Exchange(ref m_LayoutSuspended, 1);
}
public void ResumeLayout()
{
Interlocked.Exchange(ref m_LayoutSuspended, 0);
}
public bool IsLayoutSuspended
{
get { return Interlocked.Read(ref m_LayoutSuspended) != 1; }
}
I was thinking that something like that would be easier with a lock? It will indeed be used by multiple threads, hence why the use of locking/interlocked was decided.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,从到达
m_LayoutSuspended
字段的竞争角度来看,您所做的事情是安全的,但是,如果代码执行以下操作,则由于以下原因需要锁定:更安全的方法,使用
CompareExchange
以确保没有发生竞争条件:或者更好的是简单地使用锁。
Yes what you are doing is safe from a race point of view reaching the
m_LayoutSuspended
field, however, a lock is required for the following reason if the code does the following:A safer way, that uses
CompareExchange
to make sure no race conditions have occurred:Or better yet simply use a lock.
就我个人而言,我会使用易失性布尔值:
话又说回来,正如我最近在其他地方承认的那样,易失性并不完全符合我的想法。我怀疑这没关系:)
即使你坚持使用 Interlocked,我也会将其更改为 int...没有必要让 32 位系统陷入困境当他们可以用 32 位轻松完成时,使 64 位写入原子化......
Personally I'd use a volatile Boolean:
Then again, as I've recently acknowledged elsewhere, volatile doesn't mean quite what I thought it did. I suspect this is okay though :)
Even if you stick with
Interlocked
, I'd change it to anint
... there's no need to make 32 bit systems potentially struggle to make a 64 bit write atomic when they can do it easily with 32 bits...