EnterCriticalSection 多线程操作相同数据遇到的问题(线程锁)
2014-10-30 09:15
411 查看
在编程中常遇到这样的问题,线程A、B都需要用到数据Data。如线程A是用于写数据(Write)而线程B是用于读数据(Read)。一般而言这两个线程是互斥的,要不就读要不就是写。如果A线程还在运行时,B线程突然醒来,那么必然出现Data文件被占用的情况。为了避免这样的事情,我们就需要对数据进行“保护”。即在它被某个线程占用的时候,另外一个线程是不能访问它的,可以理解成让线程排队等候。EnterCriticalSection
和 LeaveCriticalSection就是现在要讲的函数,它们能做到以上所说的要求。
函数
EnterCriticalSection 声明如下:
WINBASEAPI
VOID
WINAPI
EnterCriticalSection(
__inoutLPCRITICAL_SECTION lpCriticalSection
);
LeaveCriticalSection类似,更简单的说这两个函数是用来确保同一时刻,只有一个线程对被保护的数据进行操作。相关的多线程数据函数还有
InitializeCriticalSection(&cs);//初始化临界区
EnterCriticalSection(&cs);//进入临界区
//操作数据()
MyMoney = 10;//所有访问MytMoney变量的进程都需要这样些Enter.. Leave...
LeaveCriticalSection(&cs);//离开临界区
DeleteCriticalSection(&cs);//删除临界区
比如说我们定义了一个共享资源dwTime[100],两个线程ThreadFuncA和ThreadFuncB都对它进行读写操作。当我们想要保证 dwTime[100]的操作完整性,即不希望写到一半的数据被另一个线程读取,那么用CRITICAL_SECTION来进行线程同步如下:
第一个线程函数:
DWORD WINAPI ThreadFuncA(LPVOID lp)
{
EnterCriticalSection(&cs);
...
// 操作dwTime
...
LeaveCriticalSection(&cs);
return 0;
}
写出这个函数之后,很多初学者都会错误地以为,此时cs对dwTime进行了锁定操作,dwTime处于cs的保护之中。一个“自然而然”的想法就是——cs和dwTime一一对应上了。
这么想,就大错特错了。dwTime并没有和任何东西对应,它仍然是任何其它线程都可以访问的。如果你像如下的方式来写第二个线程,那么就会有问题:
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
...
// 操作dwTime
...
return 0;
}
当线程ThreadFuncA执行了EnterCriticalSection(&cs),并开始操作dwTime[100]的时候,线程 ThreadFuncB可能随时醒过来,也开始操作dwTime[100],这样,dwTime[100]中的数据就被破坏了。
为了让CRITICAL_SECTION发挥作用,我们必须在访问dwTime的任何一个地方都加上 EnterCriticalSection(&cs)和LeaveCriticalSection(&cs)语句。所以,必须按照下面的 方式来写第二个线程函数:
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
EnterCriticalSection(&cs);
...
// 操作dwTime
...
LeaveCriticalSection(&cs);
return 0;
}
这样,当线程ThreadFuncB醒过来时,它遇到的第一个语句是EnterCriticalSection(&cs),这个语句将对cs变量 进行访问。如果这个时候第一个线程仍然在操作dwTime[100],cs变量中包含的值将告诉第二个线程,已有其它线程占用了cs。因此,第二个线程的 EnterCriticalSection(&cs)语句将不会返回,而处于挂起等待状态。直到第一个线程执行了 LeaveCriticalSection(&cs),第二个线程的EnterCriticalSection(&cs)语句才会返回,
并且继续执行下面的操作。
这个过程实际上是通过限制有且只有一个函数进入CriticalSection变量来实现代码段同步的。简单地说,对于同一个 CRITICAL_SECTION,当一个线程执行了EnterCriticalSection而没有执行LeaveCriticalSection的时 候,其它任何一个线程都无法完全执行EnterCriticalSection而不得不处于等待状态。
再次强调一次,没有任何资源被“锁定”,CRITICAL_SECTION这个东东不是针对于资源的,而是针对于不同线程间的代码段的!我们能够用它来进 行所谓资源的“锁定”,其实是因为我们在任何访问共享资源的地方都加入了EnterCriticalSection和 LeaveCriticalSection语句,使得同一时间只能够有一个线程的代码段访问到该共享资源而已(其它想访问该资源的代码段不得不等待)。
这就是使用一个CRITICAL_SECTION时的情况。你应该要知道,它并没有什么可以同步的资源的“集合”。这个概念不正确。如果是两个CRITICAL_SECTION,就以此类推。
和 LeaveCriticalSection就是现在要讲的函数,它们能做到以上所说的要求。
函数
EnterCriticalSection 声明如下:
WINBASEAPI
VOID
WINAPI
EnterCriticalSection(
__inoutLPCRITICAL_SECTION lpCriticalSection
);
LeaveCriticalSection类似,更简单的说这两个函数是用来确保同一时刻,只有一个线程对被保护的数据进行操作。相关的多线程数据函数还有
InitializeCriticalSection(&cs);//初始化临界区
EnterCriticalSection(&cs);//进入临界区
//操作数据()
MyMoney = 10;//所有访问MytMoney变量的进程都需要这样些Enter.. Leave...
LeaveCriticalSection(&cs);//离开临界区
DeleteCriticalSection(&cs);//删除临界区
比如说我们定义了一个共享资源dwTime[100],两个线程ThreadFuncA和ThreadFuncB都对它进行读写操作。当我们想要保证 dwTime[100]的操作完整性,即不希望写到一半的数据被另一个线程读取,那么用CRITICAL_SECTION来进行线程同步如下:
第一个线程函数:
DWORD WINAPI ThreadFuncA(LPVOID lp)
{
EnterCriticalSection(&cs);
...
// 操作dwTime
...
LeaveCriticalSection(&cs);
return 0;
}
写出这个函数之后,很多初学者都会错误地以为,此时cs对dwTime进行了锁定操作,dwTime处于cs的保护之中。一个“自然而然”的想法就是——cs和dwTime一一对应上了。
这么想,就大错特错了。dwTime并没有和任何东西对应,它仍然是任何其它线程都可以访问的。如果你像如下的方式来写第二个线程,那么就会有问题:
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
...
// 操作dwTime
...
return 0;
}
当线程ThreadFuncA执行了EnterCriticalSection(&cs),并开始操作dwTime[100]的时候,线程 ThreadFuncB可能随时醒过来,也开始操作dwTime[100],这样,dwTime[100]中的数据就被破坏了。
为了让CRITICAL_SECTION发挥作用,我们必须在访问dwTime的任何一个地方都加上 EnterCriticalSection(&cs)和LeaveCriticalSection(&cs)语句。所以,必须按照下面的 方式来写第二个线程函数:
DWORD WINAPI ThreadFuncB(LPVOID lp)
{
EnterCriticalSection(&cs);
...
// 操作dwTime
...
LeaveCriticalSection(&cs);
return 0;
}
这样,当线程ThreadFuncB醒过来时,它遇到的第一个语句是EnterCriticalSection(&cs),这个语句将对cs变量 进行访问。如果这个时候第一个线程仍然在操作dwTime[100],cs变量中包含的值将告诉第二个线程,已有其它线程占用了cs。因此,第二个线程的 EnterCriticalSection(&cs)语句将不会返回,而处于挂起等待状态。直到第一个线程执行了 LeaveCriticalSection(&cs),第二个线程的EnterCriticalSection(&cs)语句才会返回,
并且继续执行下面的操作。
这个过程实际上是通过限制有且只有一个函数进入CriticalSection变量来实现代码段同步的。简单地说,对于同一个 CRITICAL_SECTION,当一个线程执行了EnterCriticalSection而没有执行LeaveCriticalSection的时 候,其它任何一个线程都无法完全执行EnterCriticalSection而不得不处于等待状态。
再次强调一次,没有任何资源被“锁定”,CRITICAL_SECTION这个东东不是针对于资源的,而是针对于不同线程间的代码段的!我们能够用它来进 行所谓资源的“锁定”,其实是因为我们在任何访问共享资源的地方都加入了EnterCriticalSection和 LeaveCriticalSection语句,使得同一时间只能够有一个线程的代码段访问到该共享资源而已(其它想访问该资源的代码段不得不等待)。
这就是使用一个CRITICAL_SECTION时的情况。你应该要知道,它并没有什么可以同步的资源的“集合”。这个概念不正确。如果是两个CRITICAL_SECTION,就以此类推。
相关文章推荐
- Delphi中多线程用Synchronize实现VCL数据同步显示 解决在线程中操作控件出现问题
- 线程锁的概念函数EnterCriticalSection和LeaveCriticalSection的用法
- 多线程操作stl::map引起的数据不一致问题的解决过程与方法
- 多线程操作数据拷贝要加线程锁
- 线程锁的概念函数EnterCriticalSection和LeaveCriticalSection的用法
- 黑马程序员--读写字节数组,随机读写流,集合IO的思维导图,多线程部分,单例设计模式,线程和进程的概念,Java中的线程的创建方式,线程的随机性,线程的状态图,多线程操作共享数据的安全性,死锁
- 线程锁的概念函数EnterCriticalSection和LeaveCriticalSection的用法
- 线程锁和EnterCriticalSection、LeaveCriticalSection用法
- 线程锁的概念函数EnterCriticalSection和LeaveCriticalSection的用法
- WinForm解决多线程操作控件问题 线程间操作无效: 从不是创建控件的线程访问它"
- JAVA连接SQLServer基础,以及5分钟之内读+写20万条数据(40万条操作),遇到的问题
- C# 操作数据导出到Excel遇到的一个小问题
- 多线程中的 WaitForSingleObject 与 EnterCriticalSection 性能比较
- 多线程的原子操作和线程数据共享
- 线程锁的概念函数EnterCriticalSection和LeaveCriticalSection的用法 .
- [zz]多线程中的 WaitForSingleObject 与 EnterCriticalSection 性能比较
- 区分异步和多线程应用场景(IO操作包括获取网络数据用异步,大量耗时的计算用线程)
- 黑马程序员——java中两个线程对同一个数据做不同操作的安全问题
- 关于同一线程两次调用EnterCriticalSection的测试
- 线程锁的概念函数EnterCriticalSection和LeaveCriticalSection的用法