WinAPI _Interlocked* char、short 的内部函数

Question

我需要在 char 或 Short 上使用 _Interlocked*** 函数，但它需要长指针作为输入。似乎有函数 _InterlockedExchange8，我没有看到任何相关文档。看起来这是一个未记录的功能。此外，编译器无法找到 _InterlockedAdd8 函数。 我将不胜感激有关该功能的任何信息、使用/不使用的建议以及其他解决方案。

更新1

我会尝试简化问题。 我怎样才能做到这一点？

struct X
{
    char data;
};

X atomic_exchange(X another)
{
    return _InterlockedExchange( ??? );
}

我看到两种可能的解决方案

1. 使用 _InterlockedExchange8
2. 将 another 转换为 long，进行交换并将结果转换回 X

第一个显然是糟糕的解决方案。 第二个看起来更好，但是如何实现呢？

更新2

您对这样的事情有何看法？

template <typename T, typename U>
class padded_variable
{
public:
    padded_variable(T v): var(v) {}
    padded_variable(U v): var(*static_cast<T*>(static_cast<void*>(&v))) {}
    U& cast()
    {
        return *static_cast<U*>(static_cast<void*>(&var));
    }
    T& get()
    {
        return var;
    }
private:
    T var;
    char padding[sizeof(U) - sizeof(T)];
};

struct X
{
    char data;
};

template <typename T, int S = sizeof(T)> class var;
template <typename T> class var<T, 1>
{
public:
    var(): data(T()) {}
    T atomic_exchange(T another)
    {
        padded_variable<T, long> xch(another);
        padded_variable<T, long> res(_InterlockedExchange(&data.cast(), xch.cast()));
        return res.get();
    }
private:
    padded_variable<T, long> data;
};

谢谢。

Answer 1

制作 8 位和 16 位互锁函数非常容易，但它们不包含在 WinAPI 中的原因是由于 IA64 可移植性。如果您想支持 Win64，则汇编器不能内联，因为 MSVC 不再支持它。作为使用 MASM64 的外部函数单元，它们不会像内联代码或内在函数那么快，因此您更明智的做法是研究推广算法以使用 32 位和 64 位原子操作。

互锁 API 实现示例：intrin.asm

Answer 2

为什么要使用较小的数据类型？那么你可以将一堆它们放入一个很小的内存空间中吗？这只会导致错误共享和缓存行争用。

无论您使用锁定算法还是无锁算法，理想的做法是将数据存储在至少 128 字节的块中（或 CPU 上的任何缓存行大小），并且一次仅由一个线程使用。

Answer 3

好吧，你必须凑合使用可用的功能。 _InterlockedIncrement 和 `_InterlockedCompareExchange 有 16 位和 32 位变体（后者也有 64 位变体），也许其他一些互锁内在函数也有 16 位版本，但 InterlockedAdd 似乎不是，并且似乎根本没有字节大小的 Interlocked 内在函数/函数。

所以...您需要退后一步，弄清楚如何在没有 IntrinsicAdd8 的情况下解决您的问题。

无论如何，为什么要使用单个字节？坚持使用 int 大小的对象，除非你有充分的理由使用更小的对象。

Answer 4

创建一个新答案，因为您的编辑改变了一些内容：

• 使用_InterlockedExchange8
• 将另一个转换为 long，进行交换并将结果转换回 X

第一个根本不起作用。即使该函数存在，它也允许您一次原子地更新一个字节。这意味着对象作为一个整体将通过一系列步骤进行更新，而这些步骤不会是原子的。

第二个也不起作用，除非 X 是 long 大小的 POD 类型。 （除非它在 ​​sizeof(long) 边界上对齐，并且除非它的大小与 long 相同）

为了解决这个问题，您需要缩小范围确定 X 可能是什么类型。首先当然是保证是POD类型吗？如果不是，您将遇到完全不同的问题，因为您无法安全地将非 POD 类型视为原始内存字节。

其次，X 可以有哪些尺寸？互锁功能可以处理 16、32 位宽度，根据具体情况，也可以处理 64 甚至 128 位宽度。

这是否涵盖了您可能遇到的所有情况？

如果没有，您可能不得不放弃这些原子操作，并接受普通的旧锁。锁定互斥体以确保一次只有一个线程接触这些对象。