内存屏障VS内存交错影响缓存一致性时机 [英] Memory barrier vs Interlocked impact on memory caches coherency timing

查看:373
本文介绍了内存屏障VS内存交错影响缓存一致性时机的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

简体问题:

有没有造成联锁操作在内存缓存一致性(或冲洗)定时的差异对比记忆障碍是什么?让我们在C#中考虑 - 任何互锁操作VS Thread.MemoryBarrier()。我相信是有区别的

Is there a difference in timing of memory caches coherency (or "flushing") caused by Interlocked operations compared to Memory barriers? Let's consider in C# - any Interlocked operations vs Thread.MemoryBarrier(). I believe there is a difference.

背景:

我读到内存壁垒比较少的信息 - 预防特定类型的内存交互的指令重新排序的所有影响,但我找不到他们是否应该引起的直接的读冲洗一致信息/写队列。

I read quite few information about memory barriers - all the impact on prevention of specific types of memory interaction instructions reordering, but I couldn't find consistent info on whether they should cause immediate flushing of read/write queues.

我居然找到数源一提的还有,在操作的即时性无法保证(仅限于特定的重新排序的预防是有保障)。
例如:

I actually found few sources mentioning that there is NO guarantee on immediacy of the operation (only the prevention of specific reordering is guaranteed). E.g.

维基百科
但是,要清楚,这并不意味着任何操作都将被阻隔完成时间已经完成;只有操作完成(做完整的,当他们)是有保障的顺序

Wikipedia: "However, to be clear, it does not mean any operations WILL have completed by the time the barrier completes; only the ORDERING of the completion of operations (when they do complete) is guaranteed"

Freebsd.org (障碍是HW具体的,所以我想一个特定的操作系统无所谓):内存壁垒简单地确定内存操作的相对顺序,他们不做出关于内存操作的时机任何保证

Freebsd.org (barriers are HW specific, so I guess a specific OS doesn't matter): "memory barriers simply determine relative order of memory operations; they do not make any guarantee about timing of memory operations"

在另一方面交错操作 - 的从它们的定义 - 导致所有存储缓冲器立即冲洗,以保证最新变量的值被更新导致存储器子系统与值锁定整个高速缓存行,防止访问(包括读取)从其它任何CPU /核心,直到操作完成。

On the other hand Interlocked operations - from their definition - causes immediate flushing of all memory buffers to guarantee the most recent value of variable was updated causes memory subsystem to lock the entire cache line with the value, to prevent access (including reads) from any other CPU/core, until the operation is done.

我是正确还是我错了?

声明:

这是我原来的问题的演变这里的Variable新鲜感保证在.NET(挥发性与挥发性读)

This is an evolution of my original question here Variable freshness guarantee in .NET (volatile vs. volatile read)

EDIT1:
修正我对互锁操作声明 - 内联文本

Fixed my statement about Interlocked operations - inline the text.

EDIT2:
完全删除演示代码+它的讨论(如一些抱怨太多的信息)

Completely remove demonstration code + it's discussion (as some complained about too much information)

推荐答案

要了解C#联锁操作,你需要了解的Win32互锁操作。

To understand C# interlocked operations, you need to understand Win32 interlocked operations.

纯联锁操作本身仅影响该操作直接引用数据的新鲜度

The "pure" interlocked operations themselves only affect the freshness of the data directly referenced by the operation.

但在Win32中,联锁操作用来暗示完整的内存屏障。我认为,这主要是为了避免在更新的硬件打破旧的程序。所以InterlockedAdd做两件事:互锁的add(很便宜,不影响高速缓存)和全内存屏障(相当沉重OP)

But in Win32, interlocked operations used to imply full memory barrier. I believe this is mostly to avoid breaking old programs on newer hardware. So InterlockedAdd does two things: interlocked add (very cheap, does not affect caches) and full memory barrier (rather heavy op).

后来,微软意识到这是昂贵的,且添加所有做过任何或部分内存屏障操作版本

Later, Microsoft realized this is expensive, and added versions of each operation that does no or partial memory barrier.

所以,现在有(在Win32中的世界)四个版本几乎所有的事:例如InterlockedAdd(全栅栏),InterlockedAddAcquire(读栅栏),InterlockedAddRelease(写栅栏),纯InterlockedAddNoFence(无围墙)。​​

So there are now (in Win32 world) four versions of almost everything: e.g. InterlockedAdd (full fence), InterlockedAddAcquire (read fence), InterlockedAddRelease (write fence), pure InterlockedAddNoFence (no fence).

在C#中的世界里,只有一个版本,和它匹配的经典InterlockedAdd - 这也做完整的存储栅栏

In C# world, there is only one version, and it matches the "classic" InterlockedAdd - that also does the full memory fence.

这篇关于内存屏障VS内存交错影响缓存一致性时机的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆