假设我有一个共享对象，它有一段受关键部分保护的代码，并且有多个线程正在访问该对象进行读/写。当一个线程在临界区内时，其他线程正在等待。一旦线程离开CS，操作系统就可以访问任何等待的线程。
如果我只局限于一个进程，单独的CS是否是对共享对象的良好保护？
我问，因为我在网上看到正确的方法是使用内核对象（例如：mutex，semaphone）来保护CS。希望使用共享资源的线程需要首先使用WaitForSingleObject类型的函数获取互斥锁/信号量。如果使用互斥锁，则只有其中一个可以访问该资源。获得互斥锁后，线程进入CS，执行应该执行的操作，然后离开CS并释放互斥锁。然后OS允许任何其他等待线程获取互斥锁等等。
但是与仅使用CS不一样吗？
此外，使用互斥锁应该比单独使用CS慢得多。我只看到使用CS的唯一问题是，如果线程在CS内部崩溃，那么其他线程可能永远不会访问共享资源。
为什么这种方法更好还有其他原因吗？ 提前谢谢
答案 0 :(得分：2)
听起来你正在讨论某些特定于Windows的术语，使其与一些通用的计算机科学术语相混淆。
在计算机科学中，术语“临界区”用于必须专门运行的代码区域（通常由于数据共享）。在Windows中，有一个名为CRITICAL_SECTION的同步对象，可用于提供对执行区域的独占访问。 Windows上CRITICAL_SECTION对象的另一个属性是它仅限于在单个进程中使用。
在计算机科学中，术语“互斥体”通常用于描述可用于在并行或当前执行线程之间提供同步的对象。在Windows中，还有一个互斥对象，可以使用CreateMutex()函数（返回表示互斥锁的HANDLE）创建。该对象可用于同步相同或不同进程中的线程之间的访问，因此可以在许多方面使用类似于CRITICAL_SECTION（但具有不同的API）。如果要同步不同进程中的执行线程，可以使用互斥对象，而CRITICAL_SECTION对象则不能。
所以回答你的问题（我认为），如果你只关心保护属于同一进程的线程中的关键部分，那么CRITICAL_SECTION对象就足够了。可以使用互斥对象，但可能性能稍差。不应该使用这两种类型的对象