Critical Section和Mutex的不同点
1.Critical SectionA.速度快B.不能用于不同进程C.不能进行资源统计(每次只可以有一个线程对共享资源进行存取)2.MutexA.速度慢B.可用于不同进程C.不能进行资源统计3.SemaphoreA.速度慢B.可用于不同进程C.可进行资源统计(可以让一个或超过一个线程对共享资源进行存取)4.EventA.速度慢B.可用于不同进程C.可进行资源统计
ccriticalsection 用法 为什么是未定义标识符
CCriticalSection是对关键段CRITICAL_SECTION的封装。
关键段(critival section)是一小段代码，他在执行之前需要独占对一些共享资源的访问权。这种方式可以让多行代码以“原子方式”来对资源进行操控。这里的“原子方式”，指的是代码知道除了当前线程之外没有其他任何线程会同时访问该资源。当然，系统仍然可以暂停当前线程去调度其他线程。但是，在当前线程离开关键段之前，系统是不会去调度任何想要访问同一资源的其他线程的。
例如：如果两个线程同时访问一个链表，一个线程可能会在另一个线程搜寻元素的同时向链表中添加一个元素，将导致搜索结果不正确；还有可能两个线程同时向链表中添加元素，这种情况会变的更加混乱；甚至一个线程搜索的时候，另一个线程删除了链表节点，将直接导致程序崩溃。
解决这个问题，我们可以先在代码中定义一个CRITICAL_SECTION数据结构m_sect，然后把任何需要访问共享资源的代码放在EnterCriticalSection和LeaveCriticalSection之间。
[cpp] view plain copy print?
EnterCriticalSection(&m_sect);
// 共享资源的代码段....
LeaveCriticalSection(&m_sect);
一个 CRITICAL_SECTION结构就像是飞机上的一个卫生间，而马桶则是我们想要保护的资源（用EnterCriticalSection和LeaveCriticalSection组成的围墙包围住“马桶”）。由于卫生间很小，因此在同一时刻只允许一个人在卫生间内使用马桶（在同一时刻只允许一个线程在关键段中使用被保护资源）。
如果有多个总是应该在一起使用的资源，那么我们可以把他们放在同一个“卫生间”中：只需要创建一个CRITICAL_SECTION结构来保护所有这些资源。
关于关键段，需要掌握以下几点：
1、任何要访问共享资源的代码，都必须包含在EnterCriticalSection和LeaveCriticalSection之间。如果忘了哪怕是一个地方，共享资源就有可能被破坏。忘记调用EnterCriticalSection和LeaveCriticalSection，就好像是未经许可就强制进入卫生间一样，线程强行进入并对资源进行操控。只要有一个线程有这种粗暴的行为，资源就会被破坏。
2、关键段CRITICAL_SECTION是个未公开的结构，因为Microsoft认为开发人员不需要理解这个结构的细节。对我们来说，不需要知道这个结构中的成员变量，我们绝对不应该在编写代码的时候用到他的成员。
3、为了对CRITICAL_SECTION结构进行操控，我们必须调用Windows API函数，传入结构的地址。（注意是地址！）也就是说，如果该CRITICAL_SECTION结构生命周期没有结束，那么可以将该结构地址通过自己喜欢的任何方式传给任何线程。
4、在任何线程试图访问被保护的资源之前，必须对CRITICAL_SECTION结构的内部成员进程初始化。我们不知道内部成员，但可以调用Windows函数实现：VOID WINAPI InitializeCriticalSection(__out LPCRITICAL_SECTION lpCriticalSection);
5、当线程不再需要访问共享资源的时候，应调用下面的函数来清理该结构：VOID WINAPI DeleteCriticalSection(__inout LPCRITICAL_SECTION lpCriticalSection);
6、其实CRITICAL_SECTION并不知道什么是共享资源，也不会智能保护共享资源。其根本是，同一个时刻如果有多个线程调用EnterCriticalSection的时候，只有一个线程返回，其余线程则暂停执行，等待前面线程调用LeaveCriticalSection之后再执行。
7、可以看出，进入关键段是没有超时设定的，好像永远不会超时。实际上，对EnterCriticalSection的调用也会超时并引发异常。超时的时间长度由下面这个注册表子项中包含的CriticalSectionTimeout值决定：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
这个值以秒为单位，他的默认值为2592000秒，大约30天。
8、同一个线程可以随便进入用一个关键段N次，也就是说同一个线程调用EnterCriticalSection无论几次都会返回。不同线程是否能够进入关键段，要看EnterCriticalSection的参数（CRITICAL_SECTION结构的地址）之前是否有线程进入过。要记住：飞机上的卫生间有多个，你可以随便进入无人的卫生间，不能进入有人的卫生间。
弄明白了CRITICAL_SECTION之后，使用CCriticalSection非常方便，如虎添翼。看代码：
//头文件
[cpp] view plain copy print?
class CCriticalSection : public CSyncObjet
{...
public:
CRITICAL_SECTION m_sect;
public:
BOOL Unlock();
BOOL Lock();
BOOL Lock(DWORD dwTimeout);
...
}
// 构造函数
[cpp] view plain copy print?
CCriticalSection::CCriticalSection() : CSyncObject(NULL)
{
HRESULT hr = S_OK;
if (!InitializeCriticalSectionAndSpinCount(&m_sect, 0))//可以理解为InitializeCriticalSection，为了效率，加了一个旋转锁。
{
hr = HRESULT_FROM_WIN32(GetLastError());
}
if (FAILED(hr))
{
AtlThrow(hr);
}
}
//进入关键段
[cpp] view plain copy print?
BOOL CCriticalSection::Lock()
{
::EnterCriticalSection(&m_sect);
return TRUE;
}
// 离开关键段
[cpp] view plain copy print?
BOOL CCriticalSection::Unlock()
{
::LeaveCriticalSection(&m_sect);
return TRUE;
}
// 析构
[cpp] view plain copy print?
CCriticalSection::~CCriticalSection()
{
::DeleteCriticalSection(&m_sect);
}
windows使用临界区需要切换到内核态吗
你好，解释如下：
临界区是一种轻量级机制，在某一时间内只允许一个线程执行某个给定代码段。通常在多线程修改全局数据时会使用临界区。事件、信号量也用于多线程同步，但临界区与它们不同，并不总是执行向内核模式的切换，这一转换成本昂贵。要获得一个未占用临界区，事实上只需要对内存做出很少的修改，其速度非常快。只有在尝试获得已占用临界区时，它才会跳至内核模式。这一轻量级特性的缺点在于临界区只能用于对同一进程内的线程进行同步。
临界区由 WINNT.H 中所定义的 RTL_CRITICAL_SECTION 结构表示。 WINBASE.H 后您会发现：
typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;
操作临界区的API函数有：
（1）初始化临界区InitializeCriticalSection
（2）进入临界区EnterCriticalSection
（3）离开临界区LeaveCriticalSection
（4）删除临界区DeleteCriticalSection
在临界区未被使用的理想情况中，对 EnterCriticalSection 的调用非常快速，因为它只是读取和修改用户模式内存中的内存位置。所阻止的线程以内核模式等待，在该临界区的所有者将其释放之前，不能对这些线程进行调度。如果有多个线程被阻止于一个临界区中，当另一线程释放该临界区时，只有一个线程获得该临界区。
RTL_CRITICAL_SECTION 结构
一个进程的临界区是保存于一个链表中，并且可以对其进行枚举。实际上，WINDBG 支持 !locks 命令，这一命令可以列出目标进程中的所有临界区。
RTL_CRITICAL_SECTION 结构如下：
struct RTL_CRITICAL_SECTION
{
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread;
HANDLE LockSemaphore;
ULONG_PTR SpinCount;
};
以下各段对每个字段进行说明。
DebugInfo 此字段包含一个指针，指向系统分配的伴随结构，该结构的类型为 RTL_CRITICAL_SECTION_DEBUG。这一结构中包含更多极有价值的信息，也定义于 WINNT.H 中。LockCount 这是临界区中最重要的一个字段。它被初始化为数值 -1；此数值等于或大于 0 时，表示此临界区被占用。当其不等于 -1 时，OwningThread 字段包含了拥有此临界区的线程 ID。此字段与 (RecursionCount-1) 数值之间的差值表示有多少个其他线程在等待获得该临界区。
RecursionCount 此字段包含所有者线程已经获得该临界区的次数。如果该数值为零，下一个尝试获取该临界区的线程将会成功。
OwningThread 此字段包含当前占用此临界区的线程的线程标识符。此线程 ID 与 GetCurrentThreadId 之类的 API 所返回的 ID 相同。
LockSemaphore 它是一个内核对象句柄，用于通知操作系统：该临界区现在空闲。操作系统在一个线程第一次尝试获得该临界区，但被另一个已经拥有该临界区的线程所阻止时，自动创建这样一个句柄。应当调用 DeleteCriticalSection（它将发出一个调用该事件的 CloseHandle 调用，并在必要时释放该调试结构），否则将会发生资源泄漏。
SpinCount 仅用于多处理器系统。MSDN文档对此字段进行如下说明：“在多处理器系统中，如果该临界区不可用，调用线程将在对与该临界区相关的信号执行等待操作之前，旋转 dwSpinCount 次。如果该临界区在旋转操作期间变为可用，该调用线程就避免了等待操作。”旋转计数可以在多处理器计算机上提供更佳性能，其原因在于在一个循环中旋转通常要快于进入内核模式等待状态。此字段默认值为零，但可以用 InitializeCriticalSectionAndSpinCount API 将其设置为一个不同值。
RTL_CRITICAL_SECTION_DEBUG结构如下：
struct _RTL_CRITICAL_SECTION_DEBUG
{
WORD Type;
WORD CreatorBackTraceIndex;
RTL_CRITICAL_SECTION *CriticalSection;
LIST_ENTRY ProcessLocksList;
DWORD EntryCount;
DWORD ContentionCount;
DWORD Spare[ 2 ];
}
这一结构由InitializeCriticalSection分配和初始化。它既可以由NTDLL内的预分配数组分配，也可以由进程堆分配。RTL_CRITICAL_SECTION的这一伴随结构包含一组匹配字段，具有迥然不同的角色：有两个难以理解，随后两个提供了理解这一临界区链结构的关键，两个是重复设置的，最后两个未使用。
下面是对 RTL_CRITICAL_SECTION 字段的说明。
Type 此字段未使用，被初始化为数值 0。
CreatorBackTraceIndex 此字段仅用于诊断情形中。在注册表项 HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourProgram 之下是 keyfield、GlobalFlag 和 StackTraceDatabaseSizeInMb 值。注意，只有在运行稍后说明的 Gflags 命令时才会显示这些值。这些注册表值的设置正确时，CreatorBackTraceIndex 字段将由堆栈跟踪中所用的一个索引值填充。在 MSDN 中搜索 GFlags 文档中的短语“create user mode stack trace database”和“enlarging the user-mode stack trace database”，可以找到有关这一内容的更多信息。
CriticalSection 指向与此结构相关的 RTL_CRITICAL_SECTION。图 1 说明该基础结构以及 RTL_CRITICAL_SECTION、RTL_CRITICAL_SECTION_DEBUG 和事件链中其他参与者之间的关系。
图 1 临界区处理流程
ProcessLocksList LIST_ENTRY 是用于表示双向链表中节点的标准 Windows 数据结构。RTL_CRITICAL_SECTION_DEBUG 包含了链表的一部分，允许向前和向后遍历该临界区。本文后面给出的实用工具说明如何使用 Flink（前向链接）和 Blink（后向链接）字段在链表中的成员之间移动。任何从事过设备驱动程序或者研究过 Windows 内核的人都会非常熟悉这一数据结构。
EntryCount/ContentionCount 这些字段在相同的时间、出于相同的原因被递增。这是那些因为不能马上获得临界区而进入等待状态的线程的数目。与 LockCount 和 RecursionCount 字段不同，这些字段永远都不会递减。
Spares 这两个字段未使用，甚至未被初始化（尽管在删除临界区结构时将这些字段进行了清零）。后面将会说明，可以用这些未被使用的字段来保存有用的诊断值。
总结：
（1）如果 LockCount 字段有一个不等于 -1 的数值，此临界区被占用，OwningThread 字段包含拥有该临界区的线程的线程标识符。
（2）如果 RecursionCount 是一个大于 1 的数值，其告知您所有者线程已经重新获得该临界区多少次（也许不必要）。
（3）LockCount 与 RecursionCount 字段中分别包含其初始值 -1 和 0，这一点非常重要。事实上，对于单线程程序，不能仅通过检查这些字段来判断是否曾获得过临界区。但是，多线程程序留下了一些标记，可以用来判断是否有两个或多个线程试图同时拥有同一临界区。
（4）在该临界区未被占用时 LockSemaphore 字段中仍包含一个非零值。这表示：在某一时间，此临界区阻止了一个或多个线程。事件句柄用于通知该临界区已被释放，等待该临界区的线程之一现在可以获得该临界区并继续执行。因为 OS 在临界区阻止另一个线程时自动分配事件句柄，所以如果您在不再需要临界区时忘记将其删除，LockSemaphore 字段可能会导致程序中发生资源泄漏。
（5）在多线程程序中可能遇到的另一状态是 EntryCount 和 ContentionCount 字段包含一个大于零的数值。这两个字段保存有临界区对一个线程进行阻止的次数。在每次发生这一事件时，这两个字段被递增，但在临界区存在期间不会被递减。这些字段可用于间接确定程序的执行路径和特性。例如，EntryCount 非常高时则意味着该临界区经历着大量争用，可能会成为代码执行过程中的一个潜在瓶颈。
（6）可以通过RTL_CRITICAL_SECTION_DEBUG 中的LIST_ENTRY 遍历进程中的临界区，Flink=NULL为表头，Blink=NULL为表尾。
（7）利用RTL_CRITICAL_SECTION 的 Spare 字段可以区分我们定义的临界区和系统定义的临界区。
串行程序采用Windows32 Thread API进行线程化基本步骤？
1、将需要线程化执行的代码块抽出来，组成小函数。
2、使用CreateThread函数创建线程，并把上一步的函数名作为参数传入CreateThread中。
3、线程管理：包括设置线程优先级，线程的挂起和恢复，线程等待，线程终结。当进行线程的共享数据操作时要进行数据的互斥处理和保证线程同步。
4、释放线程所占用的资源，调用线程退出函数CloseHandle。
