在启用/clr的非托管代码中，7-Zip SDK锁实现是否安全有效？

温馨提示 #

若您要深入研究此问题，可能需要下载7-Zip SDK，因其中宏定义过多，无法全部复制粘贴。

免责声明 #

所有代码均来自7-Zip SDK，本人不享有所有权。

背景介绍 #

我正在为7-Zip SDK实现一个直接调用方法的CLR API，不使用COM组件。之前我曾成功实现过类似功能，目前正利用失业时间开发更完善的库。
该API分为两层：可供C++调用的非托管API，以及可通过CLR从C#调用的API。采用这种架构是因为老板要求使用7-Zip SDK时不得使用COM。

遇到的问题 #

我需要实现锁功能，但由于启用了/clr编译选项，无法使用std::mutex等标准库组件；同时因错误C3076（无法在原生类型中嵌入msclr::lock引用类型实例），也无法使用<msclr/lock.h>方案。
而7-Zip SDK自身有一套锁实现，且该SDK可在启用/clr的情况下成功编译。其代码位于SDK的sdk\lzma2201\CPP\Windows\Synchronization.h和sdk\lzma2201\CPP\Windows\Synchronization.cpp路径下。

我的疑问 #

这套锁实现是否是解决当前问题的有效方案？
我已在SDK相关的生产代码中使用了该实现（已获得经理批准），但不确定它是否是安全可靠的通用方案。我只是中级C开发者，对C线程同步的潜在风险了解有限。测试中未发现多线程问题，但仍有疑虑。

相关代码片段 #

来自sdk\lzma2201\CPP\Windows\Synchronization.h #

class CCriticalSection  MY_UNCOPYABLE
{
  ::CCriticalSection _object;
public:
  CCriticalSection() { CriticalSection_Init(&_object); }
  ~CCriticalSection() { CriticalSection_Delete(&_object); }
  void Enter() { CriticalSection_Enter(&_object); }
  void Leave() { CriticalSection_Leave(&_object); }
};

class CCriticalSectionLock  MY_UNCOPYABLE
{
  CCriticalSection *_object;
  void Unlock()  { _object->Leave(); }
public:
  CCriticalSectionLock(CCriticalSection &object): _object(&object) {_object->Enter(); }
  ~CCriticalSectionLock() { Unlock(); }
};

来自sdk\lzma2201\CPP\Common\MyTypes.h #

#define CLASS_NO_COPY(cls) \
  private: \
  cls(const cls &); \
  cls &operator=(const cls &);

class CUncopyable
{
protected:
  CUncopyable() {} // allow constructor
  // ~CUncopyable() {}
CLASS_NO_COPY(CUncopyable)
};

#define MY_UNCOPYABLE  :private CUncopyable
// #define MY_UNCOPYABLE

来自sdk\lzma2201\C\Threads.h #

typedef CRITICAL_SECTION CCriticalSection;
WRes CriticalSection_Init(CCriticalSection *p);
#define CriticalSection_Delete(p) DeleteCriticalSection(p)
#define CriticalSection_Enter(p) EnterCriticalSection(p)
#define CriticalSection_Leave(p) LeaveCriticalSection(p)

使用示例（来自sdk\lzma2201\CPP\UI\Console\ExtractCallbackConsole.cpp） #

#ifndef _7ZIP_ST
static NSynchronization::CCriticalSection g_CriticalSection;
#define MT_LOCK NSynchronization::CCriticalSectionLock lock(g_CriticalSection);
#else
#define MT_LOCK
#endif

后续使用：

STDMETHODIMP CExtractCallbackConsole::SetTotal(UInt64 size)
{
  MT_LOCK

  if (NeedPercents())
  {
    _percent.Total = size;
    _percent.Print();
  }
  return CheckBreak2();
}

若您认为缺少某些代码片段，可告知我。

总结 #

这套实现剥离宏定义后看起来非常简单，我不确定是否真的安全可靠。请问在启用/clr但无法使用<msclr/lock.h>的场景下，该实现是否安全？是否存在隐藏陷阱？

这套7-Zip SDK的锁实现是安全且适合你当前场景的方案，理由如下：

1. 底层依赖可靠
   它本质是对Windows原生CRITICAL_SECTION的轻量封装。CRITICAL_SECTION是Windows平台成熟的用户态同步原语，专为单进程内的线程同步设计，性能优于互斥量（Mutex），且在启用/clr的编译环境下能正常工作——因为它是纯原生Windows API，不依赖C++标准库或CLR特定的引用类型，完全避开了你遇到的C3076错误。

2. RAII实现正确
   CCriticalSectionLock采用了RAII（资源获取即初始化）模式：构造时自动调用Enter()，析构时自动调用Leave()。这确保了锁会在作用域结束时自动释放，即使代码抛出异常也不会出现死锁风险，这是线程同步中最安全的实践方式之一。

3. 不可拷贝设计合理
   通过MY_UNCOPYABLE宏禁用了拷贝构造和赋值运算符，避免了锁对象被意外拷贝导致的同步逻辑混乱，这是同步类的标准安全设计。

潜在注意事项（隐藏陷阱） #

虽然实现本身安全，但使用时需要注意几个点：

• 递归调用风险：CRITICAL_SECTION支持递归获取（同一线程可多次调用Enter()），但如果你的代码中存在不恰当的递归逻辑，可能会导致锁的持有时间过长，甚至引发死锁（比如不同线程的锁依赖链交叉）。
• 作用域控制：MT_LOCK宏定义的锁是局部变量，作用域仅限当前函数。如果需要跨函数的同步，要确保锁对象的生命周期覆盖所有需要同步的代码段，避免锁对象提前销毁。
• 单进程限制：CRITICAL_SECTION仅适用于单进程内的线程同步，如果你的后续扩展需要跨进程同步，这套实现就不适用了，但根据你的背景，当前场景是单进程内的CLR API，所以没问题。
• 异常安全：虽然RAII保证了异常下的锁释放，但要确保CriticalSection_Leave()本身不会抛出异常——Windows的LeaveCriticalSection()是不会抛出异常的，所以这一点无需担心。

结论 #

在你当前启用/clr且不能使用标准库或msclr::lock的场景下，这套7-Zip的锁实现是完全可靠的选择。它经过7-Zip产品级代码的验证，且符合线程同步的最佳实践，你可以放心使用。

内容的提问来源于stack exchange，提问作者mWellington