CN1917504A - 一种避免资源数据共享访问导致死锁的加锁方法 - Google Patents
一种避免资源数据共享访问导致死锁的加锁方法 Download PDFInfo
- Publication number
- CN1917504A CN1917504A CN 200510041587 CN200510041587A CN1917504A CN 1917504 A CN1917504 A CN 1917504A CN 200510041587 CN200510041587 CN 200510041587 CN 200510041587 A CN200510041587 A CN 200510041587A CN 1917504 A CN1917504 A CN 1917504A
- Authority
- CN
- China
- Prior art keywords
- thread
- resource
- lock
- vector
- resources
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种避免资源数据共享访问导致死锁的加锁方法,用于实现对传送网层网络管理系统中的多线程加锁,其中,所述多线程中的线程申请锁资源的时候,所述线程能够申请到所述锁资源,且所述线程分配到所述锁资源后系统处于安全状态,则将所述锁资源分配给所述线程,否则设置所述线程为等待状态,线程得到所有锁资源后且对资源数据访问后释放锁,并唤醒等待中的线程。采用本发明所述的避免资源数据共享访问导致死锁的加锁方法,实现了死锁检测和避免的自动化操作的进步,达到了方便用户使用的效果,节省了繁琐的加锁过程,同时还做到了死锁的检测和避免,提高了系统稳定性。
Description
技术领域
本发明涉及传送网层网络管理系统中的层网络资源数据共享访问,特别是一种传送网层网络管理系统中的避免资源数据共享访问而导致死锁的方法。
背景技术
在大型传送网层网络管理系统中,可能存在大量的线程,它们往往需要访问大量共享的资源数据,为了避免数据读写的不一致性,线程在访问共享资源前必须先加锁,获得锁后才能够访问资源数据;而加锁类型往往包括互斥锁和读写锁,但是传送网层网络的业务处理过程复杂,加锁和解锁操作千丝万缕,如果没有一种有效的避免死锁的加锁策略,往往会导致死锁的发生,并会引起一些莫名其妙的问题,引起整个系统瘫痪;并且发生死锁后比较难诊断,将会花费很大的工作量,而且打破死锁使程序继续执行更变得十分困难。
在层网络管理系统中,往往存在m种类型的资源数据和n个线程,线程访问数据前需要在数据上加读写锁或互斥锁,采用如下数据结构来描述层网络管理系统中共享访问层网络资源数据的模型结构,其中:
T={T1,T1,T3…Tn}代表线程的一个集合;
R={R0,R1,R2…Rm}代表系统的资源集合,是一个含有m个元素的一维数组,其中的每一个元素代表一类可利用的资源数目,其初值是系统中所配置的该类资源全部可用最大的数目,使用数据结构Available[m]来描述当前可用资源数目,Available[j]=k,表示系统中现有Rj类资源K个;
Max[n,m],最大需求矩阵,n*m的矩阵,定义n个线程中的每一线程对m类资源的最大需求,满足了它的最大需求就能够执行完毕,如Max(i,j)=K表示线程i需要Rj类资源的最大数目为k,只有获取了k个资源才能执行完毕;
Ti指向Rj的箭头代表线程Ti申请资源Rj,Rj指向Ti的箭头代表资源已分配给线程Ti;
资源分配:根据图1资源数据分配模型,使用资源分配图刻画系统某一时框表示资源Rj)使用资源分配图刻画系统某一时刻状态,图2和图3两个资源分配图描述了系统两个不同时刻的资源分配状态;
Allocation[n,m],资源分配状态矩阵,表示线程资源分配状态,n*m矩阵,定义系统中每一类资源当前已分配给每一线程资源数,Allocation(i,j)=k表示线程i当前已获得Rj类资源k个,如图2中的线程P1和P2,已经各获得一个R2资源,资源R2已经没有可用资源了,P1仍需要一个R1资源,相应数据结构可以表示为:Allocation[1,1]=0、Allocation[1,2]=1、Allocation[2,2]=1、Available[2]=0、Max[1,1]=1及Max[1,2]=1;
Need[n,m],线程需求资源矩阵,表示每一线程还需要多少资源才能执行完毕,如Need[i,j]=k表示线程i还需k个资源Rj的实例才能执行完毕,且:
Need[i,j]=Max[i,j]-Allocation[i,j]
图2是存在循环等待并发生了死锁的资源分配图,而图3是存在循环等待但没有死锁的资源分配图。
层网络中的每种类型的数据对应一把读写锁或者互斥锁,如果系统存在MAXLOCK个读写锁,那么系统对应着2*MAXLOCK个“资源类型”,每一读写锁对应着“读锁资源类型”和“写锁资源类型”,这两种资源类型数目在系统初始化的时候值为∞和1,也就是说最大资源数为2MAXLOCK,互斥锁也对应“读锁资源类型”和“写锁资源类型”,只是“读锁资源类型”在系统初始化的时候值为零。
按照读写锁原则:可以同时对数据加多个读锁,但不能加任何写锁;同时只可以对数据加一个写锁,不能加其他任何的读锁和写锁;同时只可以对数据加一个互斥锁,所以每一时刻每种类型的数据对应着系统中已分配资源和可用资源存在如下状态:
同一时刻已分配资源状态存在三种状态,如下表所示:
序号 | 读锁资源 | 写锁资源 | 意义 |
1 | <∞ | 0 | 分配了多个读锁 |
2 | ∞ | 1 | 分配了一个写锁 |
3 | 0 | 1 | 分配了互斥锁 |
同一时刻可用资源状态存在两种状态,如下表所示:
序号 | 读锁资源 | 写锁资源 | 意义 |
1 | <∞ | 0 | 分配了多个读锁 |
2 | 0 | 0 | 分配了一个写锁或互斥锁 |
用上述模型结构描述层网络管理系统中,两个不同线程对路径和拓扑资源数据共享访问导致死锁与不死锁时的资源分配图,分别如图4和图5所示。
在层网络管理系统中,如果不加任何的措施和方法,死锁很容易发生。
发明内容
本发明的目的在于提供一种避免资源数据共享访问导致死锁的加锁方法,避免资源数据共享访问导致死锁的加锁方法能确保系统不进入死锁状态,即保证系统处在安全状态,避免死锁的出现。
为了实现上述目的,本发明提供了一种避免资源数据共享访问导致死锁的加锁方法,用于实现对传送网层网络管理系统中的多线程加锁,其中,所述多线程中的线程申请锁资源的时候,所述线程能够申请到所述锁资源,且所述线程分配到所述锁资源后系统处于安全状态,则将所述锁资源分配给所述线程,否则设置所述线程为等待状态,线程得到所有锁资源后且对资源数据访问后释放锁,并唤醒等待中的线程。
上述的一种避免资源数据共享访问导致死锁的加锁方法,其中,线程得到所有锁资源后且对资源数据访问后按照加锁顺序释放锁。
上述的一种避免资源数据共享访问导致死锁的加锁方法,其中,当且仅当每一个线程所申请的可被满足的资源数加上其他线程所持有的该资源数小于或等于系统所有资源类型数目的总数时系统处于安全状态。
上述的一种避免资源数据共享访问导致死锁的加锁方法,其中,具体包括以下步骤:
步骤1,执行系统的初始化,对数据结构和锁资源执行的初始化;
步骤2,所述多线程中的一第一线程申请锁,所述第一线程能申请到所述锁,且所述第一线程在申请到所述锁后系统处于所述安全状态则将数据资源数据分配给所述第一线程并处理下一线程的锁请求,否则将所述第一线程设置为等待状态并处理下一线程的锁请求;及
步骤3,所述多线程中的任意线程在获取所有锁资源后访问资源数据,完成资源数据的访问后释放锁,并完成资源的复位,同时唤醒等待中的线程继续执行加锁操作。
上述的一种避免资源数据共享访问导致死锁的加锁方法,其中,所述步骤1具体执行以下操作:把资源分配状态矩阵和最大需求矩阵初始化为零,并初始化系统的锁数目、线程数目、资源数目、可用资源向量及线程需求资源矩阵。
上述的一种避免资源数据共享访问导致死锁的加锁方法,其中,所述步骤2具体包括以下步骤:
步骤211,所述第一线程发出锁请求后,修改所述第一线程的最大需求向量,并判断所述第一线程的资源请求向量是否小于或等于所述第一线程的最大需求向量,如果是转向步骤212,否则判断为出错,处理下一线程的锁请求;
步骤212,判断所述第一线程的资源请求向量是否小于或等于所述可用资源向量,如果是转向步骤213,否则将所述第一线程设置为等待状态并处理所述下一线程的锁请求;
步骤213,尝试把申请的资源分配给所述第一线程,并修改所述资源分配状态矩阵、可用资源向量及所述第一线程的需求资源矩阵;
步骤22,检查此次资源分配后系统是否处于安全状态,若是将锁分配给所述第一线程完成本次分配,否将尝试分配的锁作废,设置所述第一线程为等待状态,并恢复原来的资源分配状态。
上述的一种避免资源数据共享访问导致死锁的加锁方法,其中,所述步骤22具体包括以下步骤:
步骤221,设置一工作向量和一资源判断向量;
步骤222,判断是否存在资源判断向量中对应元素为假,且需求向量中的每个元素的值是小于或等于所述工作向量中对应元素[0]的值的线程,是进入步骤223,否则进入步骤225;
步骤223,修改线程的工作向量和资源判断向量,并返回步骤222进行下一线程的判断;
步骤224,所有线程判断完毕后,判断是否资源判断向量的元素是否全为真,如果是系统正式将所述第一线程申请的锁资源分配给所述第一线程;
步骤225,设置所述第一线程为等待状态,并修改所述资源分配状态矩阵、可用资源向量及所述第一线程的需求资源矩阵,并返回所述步骤211处理下一线程的锁请求。
采用本发明所述的避免资源数据共享访问导致死锁的加锁方法,通过尝试分配锁资源,然后对系统的安全状态进行判断,如果不安全则设置线程为等待状态,等待被唤醒,线程得到所有锁资源后且对资源数据访问后释放锁,并唤醒等待中的线程,本发明的方法取得了死锁检测和避免的自动化操作的进步,达到了方便用户使用的效果,节省了繁琐的加锁过程,同时还做到了死锁的检测和避免,提高了系统稳定性。
附图说明
图1是资源数据分配模型图;
图2是一种存在死锁的资源分配图;
图3是存在环但不死锁的资源分配图;
图4是层网络管理系统中存在死锁的资源分配图;
图5是层网络管理系统中存在不死锁的资源分配图;
图6是两个线程访问两种数据类型即将发生死锁时候资源分配图;
图7到图32是本发明第二实施例中每一时刻申请加锁时对应的资源分配图;
具体实施方式
本发明的避免资源数据共享访问导致死锁的加锁方法能确保系统不进入死锁状态,即保证系统处在安全状态,能够避免死锁的出现。
如图6所示,在线程P1已经先获取一个R1,同时它需要再获取一个R2才能执行完毕,但是当它提出申请R1资源的时候,本发明的避免资源数据共享访问导致死锁的加锁方法检测到系统将可能出现死锁,因为P2已经获得了资源R2,并且下一步要获取R1资源,如果这个时候将R1分配给P1,如果P2下一步申请R1资源的时候,死锁就有可能发生。所以本发明的避免资源数据共享访问导致死锁的加锁方法就让P1在申请资源R1的时候等待,直到系统处于安全状态后被唤醒。
总的来说当某个线程申请了资源的时候,在该线程能够申请到该资源前提下,判断是否在申请资源后能够找到一个安全序列,让系统处于安全状态,否则不能把该资源分配给该线程,该线程就需要等待一段时间;当一个线程得到所有的资源,它必须在有限的时间释放它们。
定义线程序列是安全的,当且仅当每一个线程Ti所申请的可以被满足的资源数加上其他线程所持有的该资源数小于或等于系统所有资源类型数目的总数,如果一个系统在安全状态,就没有死锁,如果一个系统不是处于安全状态,就有可能发生死锁。
本发明的避免资源数据共享访问导致死锁的加锁方法分三个步骤,如下所示:
步骤1,执行系统的初始化,主要是数据结构的初始化和锁资源的初始化,包括把资源分配状态矩阵Allocation[n,m]和最大需求矩阵Max[n,m]初始化为零,并且初始化系统的锁资源;
步骤2,将用户的加锁操作转化为对系统资源的申请操作:申请锁,并将锁的请求转换为执行资源请求方法和系统状态判断及执行方法,如果预分配锁资源后系统处于安全状态,则表示可以加锁成功,并正式将资源分配给线程完成本次分配,否则需要线程等待系统处于安全状态后被唤醒;及
步骤3,线程在获取所有锁资源后访问资源数据,完成资源数据的访问后释放锁,并完成相关资源的复位,同时唤醒等待中的线程继续执行加锁操作。
在线程成功获得锁并且对资源数据访问完毕后,需要解锁,解锁操作的输入参数与加锁操作输入参数相同,它的处理流程是按照加锁顺序进行资源的释放,并通过释放的信号量通知等待的线程,从而唤醒在等待的线程。
上述的步骤2中的资源请求方法如下所述:
设Requesti是线程Ti的当前时刻资源请求向量,是维数为m的向量,表示线程Ti对m种资源的请求,假设线程Ti需要K个Rj类资源,当Ti发出资源请求后,系统按下述步骤进行检查:
步骤211,修改线程Ti的最大需求向量MaxNeedi,并判断Requesti中的每个元素的值是否小于或等于MaxNeedi中对应元素[0]的值,如果是转向步骤212;否则认为出错,因为它所需要的资源数已超过资源可用数的最大值,并返回步骤211处理下一线程的锁请求;
步骤212,判断Requesti中的每个元素的值是否小于或等于Available中对应元素[0]的值,如果是转向步骤213;否则,表示系统中尚无足够的资源,将线程Ti设置为等待状态并返回步骤211处理所述下一线程的锁请求;
步骤213,系统尝试把申请的资源分配给线程Ti,并修改下面数据结构中的数值:
Available:=Available-Requesti;
Allocation:=Allocation+Requesti;
Needi:=Needi-Requesti;
上述的步骤2中的系统状态判断及执行方法检查此次资源分配后系统是否处于安全状态,若安全,正式将资源分配给线程Ti完成本次分配,否则,将尝试分配的资源作废,恢复原来的资源分配状态,让线程Ti等待;系统状态判断方法具体包括以下步骤来执行:
步骤221,设置两个一维数组向量,分别为:
Work,工作向量,表示系统可提供给线程继续运行所需要的各类资源的数目,包括m个元素,方法开始时,Work:=Available;
Finish,资源判断向量,表示系统是否有足够的资源分配给线程Ti,使之运行完成,开始时Finish[i]:=false;当有足够的资源分配给线程时,Finish[i]:=true:
步骤222,从线程集合中找到能满足下述条件的线程:
Finish[i]=FALSE,且Needi中的每个元素的值是小于或等于Work中对应元素[0]的值;
如果能找到则执行步骤223,否则执行步骤225;
步骤223,设置
Work:=Work+Allocation;
Finish[i]:=TRUE;
然后返回步骤222执行下一线程的判断;
步骤224,所有线程循环执行完毕,判断是否所有线程的Finish[i]:=TRUE,如果是表明系统处于安全状态,系统正式将线程Ti申请的资源分配给线程Ti,否则执行步骤225;
步骤224,系统处于不安全状态,设置线程Ti为等待状态,并修改所述资源分配状态矩阵、可用资源向量及所述第一线程的需求资源矩阵,并返回所述步骤211处理下一线程的锁请求。
假设层网络管理系统中存在两种数据类型,共有两个线程对数据进行操作,操作包括读和写,所以系统初始化的时候,系统的锁资源初始化为{RW_LOCK_TYPE,RW_LOCK_TYPE},并且假设现在线程T0要先后发出对数据1的写锁和对数据2的读锁;而线程T1要先后发出对数据2的写锁和对数据1的读锁,如下表所示:
数据1 | 数据2 | |
T0 | W | R |
T1 | R | W |
如果线程T0和线程T1先后分别获得对数据1的写锁和对数据2的写锁,就会出现图4中的死锁情况,下面结合上述的发明避免死锁的发生。
这两个线程在执行对资源数据的访问前,必须能够获得所有锁,为此假设它们先后发出加锁请求。
在时刻Time(0)进行系统的的初始化,其中:
MAXLOCK=2(锁的个数);n=2(线程个数);m=4(资源个数)
可用资源如下表所示:
Availiable | R0 | R1 | R2 | R3 |
可用资源数目 | ∞ | 1 | ∞ | 1 |
因为一个读写锁对应两个资源类型,一个是读锁资源,一个是写锁资源,按照读写锁原则,线程申请了读锁,其它线程还可以申请读锁,但写锁只能申请一次,所以初始化读锁值无穷,写锁为1,在实际中,读锁值的无穷通过整型的最大值表示。
线程最多申请资源如下表所示:
Max | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 0 | 0 | 0 | 0 |
已分配给线程的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 0 | 0 | 0 | 0 |
线程还需要的资源如下表所示:
Need | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 0 | 0 | 0 | 0 |
时刻Time(1)对线程T0执行加锁请求:
T0要先对数据1加写锁,后对数据2读锁;T0修改线程最多申请资源的数据结构结果如下:
Max | R0 | R1 | R2 | R3 |
T0 | 0 | 1 | 1 | 0 |
T1 | 0 | 0 | 0 | 0 |
T0尝试获取数据1的写锁,成功后执行资源请求方法,T0修改相应的数据结构:
已经分配给线程的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | ∞ | 1 | 0 | 0 |
T1 | 0 | 0 | 0 | 0 |
可用资源如下表所示:
Availiable | R0 | R1 | R2 | R3 |
可用资源数目 | 0 | 0 | ∞ | 1 |
线程还需要的资源如下表所示:
Need | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 1 | 0 |
T1 | 0 | 0 | 0 | 0 |
执行系统状态判断方法,判断当前系统处于安全状态。
时刻Time(2)对T1执行加锁请求:
T1要先对数据2加写锁和后对数据1加读锁;T1修改线程最多申请资源的数据结构结果如下:
Max | R0 | R1 | R2 | R3 |
T0 | 0 | 1 | 1 | 0 |
T1 | 1 | 0 | 0 | 1 |
T1尝试获取数据2的锁,成功后,将发出资源请求,在资源请求方法中,T1修改相应的数据结构:已分配资源、可用资源和还需要的资源。
已经分配给线程的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | ∞ | 1 | 0 | 0 |
T1 | 0 | 0 | ∞ | 1 |
可用资源如下表所示:
Availiable | R0 | R1 | R2 | R3 |
可用资源数目 | 0 | 0 | 0 | 0 |
线程还需要的资源如下表所示:
Need | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 1 | 0 |
T1 | 1 | 0 | 0 | 0 |
判断当前系统处于非安全状态:可用资源信息中看出可用资源为零,将导致T0和T1下一步都不能获得锁,于是资源请求方法将T1之前获得的资源释放,并修改相应的数据结构:
已经分配给线程的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | ∞ | 1 | 0 | 0 |
T1 | 0 | 0 | 0 | 0 |
可用资源如下表所示:
Availiable | R0 | R1 | R2 | R3 |
可用资源数目 | 0 | 0 | ∞ | 0 |
线程还需要的资源如下表所示:
Need | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 1 | 0 |
T1 | 1 | 0 | 0 | 1 |
T1将之前获得对数据2的锁释放,并等待系统处于安全状态后被唤醒。
时刻Time(3)继续执行线程T0的GetLock请求:
T0尝试获取数据2的锁,成功后,将发出资源请求,在资源请求方法中,T0修改相应的数据结构:
已经分配给线程的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | ∞ | 1 | 1 | 0 |
T1 | 0 | 0 | 0 | 0 |
可用资源如下表所示:
Availiable | R0 | R1 | R2 | R3 |
可用资源数目 | 0 | 0 | ∞-1 | 0 |
其中∞-1表示其他线程还可以获取数据2的读锁;线程还需要的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 1 | 0 | 0 | 1 |
根据系统状态判断方法判断当前系统处于安全状态,于是T0获得了所有的锁,可以访问资源数据了;
时刻Time(4)线程T0获得锁后执行完业务处理的流程,发出解锁请求:
T0成功解锁后,释放所拥有的资源,并修改相应的数据结构:
最多申请资源如下表所示:
Max | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 1 | 0 | 0 | 1 |
已经分配给线程的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 0 | 0 | 0 | 0 |
可用资源如下表所示:
Availiable | R0 | R1 | R2 | R3 |
可用资源数目 | ∞ | 1 | ∞ | 1 |
线程还需要的资源如下表所示:
Allocation | R0 | R1 | R2 | R3 |
T0 | 0 | 0 | 0 | 0 |
T1 | 1 | 0 | 0 | 1 |
在时刻Time(4)前线程T1处在等待被唤醒的状态下,在线程T0成功解锁后,T0将并通过信号量唤醒等待的T1线程;
时刻Time(5)线程T1被线程T0唤醒,发出申请对数据2的写锁和对数据1的读锁请求,由于避免了死锁,线程T1执行完毕后,线程T0也能够顺利的执行
上述实施例是针对两个线程和两种数据类型,下面我们进一步扩展,假设当前系统中共有五个线程,访问四种共享资源,都是要加读写锁类型的锁,其包括以下步骤:
步骤S1,修改三个常量值:
const int MAXLOCK=4;表明系统所使用的读写锁数目为4;
const int MAXRES=8;表明资源类型数目为8,即2倍MAXLOCK;
const int MAXPRO=5;表明进程或者线程数目为5;
步骤S2,初始化系统锁资源为{RW_LOCK_TYPE,RW_LOCK_TYPE,RW_LOCK_TYPE,RW_LOCK_TYPE};
步骤S3,创建五个线程,线程体分别实现:
线程1:先获取数据RW4的读锁,后去获取数据RW1的读锁;
线程2:先获取数据RW1的写锁,后去获取数据RW2的读锁;
线程3:先获取数据RW2的写锁,后去获取数据RW3的写锁;
线程4:先获取数据RW3的读锁,后去获取数据RW4的写锁;
线程5:先获取数据RW4的写锁,后去获取数据RW3的读锁,在获取RW1的写锁,最后获取数据RW2的写锁;
假设线程的启动顺序是5,1,4,3,2,我们使用资源分配图来描述整个执行过程。
Time1时刻:线程5启动,尝试获取RW4的写锁成功,资源分配图如图7所示;
Time2时刻:线程1启动,要尝试先获取RW4的读锁,由于写锁已经分配给T4,所以线程1阻塞在获取RW4的写锁上,资源分配图如8所示;
Time3时刻:线程4启动,先尝试获取RW3的读锁成功;资源分配图如图9所示;
Time4时刻:线程3启动,要尝试先获取RW2的写锁;资源分配图如图10所示;如果将RW2写锁分配给T3,本发明的避免资源数据共享访问导致死锁的加锁方法检查到存在循环等待环,如图10中的虚线环,所以系统让线程3阻塞在获取RW2的写锁上;如图11所示;
Time5时刻:线程2启动,要尝试先获取RW1的写锁成功;资源分配图如图12所示。
Time6时刻:线程4(已经获得了RW3的读锁)尝试去获取RW4的写锁,因为RW4已经把写锁分配给线程T5,所以线程4将阻塞在获取RW4的写锁上,资源分配图如图13所示;
Time7时刻:线程5(已经获得了RW4的写锁)尝试去获取RW3的读锁,由于RW3可以分配多个读锁,所以线程5获取成功,资源分配图如图14所示;
Time8时刻:线程2(已经获得了RW1的写锁)尝试获取RW2的读锁成功,至此,线程2获得所有锁;资源分配图如图15所示;
Time9时刻:线程5(已经获得了RW4的写锁和RW3的读锁)尝试去获取RW2的写锁,由于RW2的读锁已经分配给T2,所以T5将阻塞在获取RW2的写锁上,资源分配图如图16所示;
Time10时刻:线程2(已经获得了RW1的写锁和RW2的读锁)访问完资源数据后,释放锁,也就是释放已经获得的RW1的写锁和RW2的读锁,那么它就会同时唤醒T3和T5,线程是先唤醒T3,后唤醒T5的,因为T3时首先等待的,资源分配图如图17所示;
Time11时刻:线程3被线程2首先被唤醒后,尝试去获取RW2的写锁,资源分配图如图18所示;如果将该写锁分配给线程3,本发明的避免资源数据共享访问导致死锁的加锁方法检查到存在循环等待环,如图18中的虚线环,所以系统让T3再次阻塞在获取RW2的写锁上,如图19所示;
Time12:线程5被线程2唤醒,尝试获取RW2的写锁成功,如图20所示;
Time13:线程5尝试继续获取RW1的读锁成功,至此线程5已经获得了所有锁,资源分配图如图21所示;
Time14:线程5访问完资源数据后,按照获得所的顺序释放锁,也就是先释放RW4的写锁,后释放RW3的读锁,再释放RW2的写锁,最后是释放RW1的写锁,所以顺序地唤醒T1、T4、T3,如图22所示。
Time15:线程1首先被线程5唤醒,尝试去获得RW4的写锁成功,资源分配图如图23所示;
Time16:线程4被线程5唤醒,尝试去获得RW4的写锁,由于写锁已经分配给线程1,所以阻塞在获取RW4的写锁上,资源分配图如图24所示;
Time17:线程3被线程5唤醒,尝试去获取RW2的写锁成功,资源分配图如图25所示;
Time18:线程1尝试继续获取RW1的读锁成功,至此线程1获取了全部锁,资源分配图如图26所示;
Time19:线程3继续尝试去获取RW3的写锁,由于RW3的读锁已经分配给线程4,所以线程3阻塞在获取RW3的写锁上,资源分配图如图27所示;
Time20:线程1释放已经获得的锁(RW4的写锁和RW1的读锁),唤醒等待的线程4,资源分配图如图28所示;
Time21:线程4被线程1唤醒,尝试获取RW4的写锁成功,至此线程4已经获取了所有锁,资源分配图如图29所示;
Time22:线程4释放拥有的锁,唤醒等待的线程3,资源分配图如图30所示;
Time23:线程3被线程4唤醒,尝试获取RW3的写锁成功,资源分配图如图31所示;
Time24:线程3使用所拥有的锁,至此所有线程都执行完毕,资源分配图如图32所示。
当然,本发明还可有其它多种实施例,在不背离本发明精神及其实质的情况下,熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形,但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
Claims (7)
1、一种避免资源数据共享访问导致死锁的加锁方法,用于实现对传送网层网络管理系统中的多线程加锁,其特征在于,所述多线程中的线程申请锁资源的时候,所述线程能够申请到所述锁资源,且所述线程分配到所述锁资源后系统处于安全状态,则将所述锁资源分配给所述线程,否则设置所述线程为等待状态,线程得到所有锁资源后且对资源数据访问后释放锁,并唤醒等待中的线程。
2、根据权利要求1所述的一种避免资源数据共享访问导致死锁的加锁方法,其特征在于,线程得到所有锁资源后且对资源数据访问后按照加锁顺序释放锁。
3、根据权利要求1或2所述的一种避免资源数据共享访问导致死锁的加锁方法,其特征在于,当且仅当每一个线程所申请的可被满足的资源数加上其他线程所持有的该资源数小于或等于系统所有资源类型数目的总数时系统处于安全状态。
4、根据权利要求3所述的一种避免资源数据共享访问导致死锁的加锁方法,其特征在于,具体包括以下步骤:
步骤1,执行系统的初始化,对数据结构和锁资源执行的初始化;
步骤2,所述多线程中的一第一线程申请锁,所述第一线程能申请到所述锁,且所述第一线程在申请到所述锁后系统处于所述安全状态则将数据资源数据分配给所述第一线程并处理下一线程的锁请求,否则将所述第一线程设置为等待状态并处理下一线程的锁请求;及
步骤3,所述多线程中的任意线程在获取所有锁资源后访问资源数据,完成资源数据的访问后释放锁,并完成资源的复位,同时唤醒等待中的线程继续执行加锁操作。
5、根据权利要求4所述的一种避免资源数据共享访问导致死锁的加锁方法,其特征在于,所述步骤1具体执行以下操作:把资源分配状态矩阵和最大需求矩阵初始化为零,并初始化系统的锁数目、线程数目、资源数目、可用资源向量及线程需求资源矩阵。
6、根据权利要求4或5所述的一种避免资源数据共享访问导致死锁的加锁方法,其特征在于,所述步骤2具体包括以下步骤:
步骤211,所述第一线程发出锁请求后,修改所述第一线程的最大需求向量,并判断所述第一线程的资源请求向量是否小于或等于所述第一线程的最大需求向量,如果是转向步骤212,否则判断为出错,重复步骤211处理下一线程的锁请求;
步骤212,判断所述第一线程的资源请求向量是否小于或等于所述可用资源向量,如果是转向步骤213,否则将所述第一线程设置为等待状态并返回所述步骤211处理所述下一线程的锁请求;
步骤213,尝试把申请的资源分配给所述第一线程,修改所述资源分配状态矩阵、可用资源向量及所述第一线程的需求资源矩阵;
步骤22,检查此次资源分配后系统是否处于安全状态,若是将锁分配给所述第一线程完成本次分配,否将尝试分配的锁作废,设置所述第一线程为等待状态,并恢复原来的资源分配状态。
7、根据权利要求6所述的一种避免资源数据共享访问导致死锁的加锁方法,其特征在于,所述步骤22具体包括以下步骤:
步骤221,设置一工作向量和一资源判断向量;
步骤222,判断是否存在资源判断向量中对应元素为假,且需求向量中的每个元素的值是小于或等于所述工作向量中对应元素[0]的值的线程,是进入步骤223,否则进入步骤225;
步骤223,修改线程的工作向量和资源判断向量,并返回步骤222进行下一线程的判断;
步骤224,所有线程判断完毕后,判断是否资源判断向量的元素是否全为真,如果是系统正式将所述第一线程申请的锁资源分配给所述第一线程;
步骤225,设置所述第一线程为等待状态,并修改所述资源分配状态矩阵、可用资源向量及所述第一线程的需求资源矩阵,并返回所述步骤211处理下一线程的锁请求。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200510041587 CN1917504A (zh) | 2005-08-20 | 2005-08-20 | 一种避免资源数据共享访问导致死锁的加锁方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200510041587 CN1917504A (zh) | 2005-08-20 | 2005-08-20 | 一种避免资源数据共享访问导致死锁的加锁方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1917504A true CN1917504A (zh) | 2007-02-21 |
Family
ID=37738399
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 200510041587 Pending CN1917504A (zh) | 2005-08-20 | 2005-08-20 | 一种避免资源数据共享访问导致死锁的加锁方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1917504A (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102640113A (zh) * | 2009-12-04 | 2012-08-15 | 微软公司 | 针对分布式持久实例的锁定解决 |
CN102662747A (zh) * | 2012-04-23 | 2012-09-12 | 深圳市融创天下科技股份有限公司 | 一种线程访问临界区的方法、系统和终端设备 |
CN103064729A (zh) * | 2012-12-19 | 2013-04-24 | 上海西本网络科技有限公司 | 对共享资源的加锁、控制方法和装置 |
CN103176848A (zh) * | 2011-11-08 | 2013-06-26 | 辉达公司 | 计算工作分布参考计数器 |
CN103246552A (zh) * | 2012-02-14 | 2013-08-14 | 腾讯科技(深圳)有限公司 | 防止线程出现阻塞的方法和装置 |
CN103473137A (zh) * | 2013-09-16 | 2013-12-25 | 东软集团股份有限公司 | 避免死锁的资源分配方法及系统 |
CN103678991A (zh) * | 2012-08-30 | 2014-03-26 | 想象力科技有限公司 | 多线程处理器中的全局寄存器保护 |
CN103946827A (zh) * | 2011-11-22 | 2014-07-23 | 华为技术有限公司 | 用于实施内核和用户空间之间共享的锁的系统和方法 |
CN104702655A (zh) * | 2014-03-21 | 2015-06-10 | 杭州海康威视系统技术有限公司 | 云存储资源分配方法及其系统 |
CN105700939A (zh) * | 2016-04-21 | 2016-06-22 | 北京京东尚科信息技术有限公司 | 一种分布式系统中多线程同步的方法和系统 |
CN106407016A (zh) * | 2016-10-19 | 2017-02-15 | 腾讯科技(深圳)有限公司 | 一种多线程争抢资源的模拟方法及装置 |
CN106681809A (zh) * | 2016-12-05 | 2017-05-17 | 上海斐讯数据通信技术有限公司 | 一种基于锁的线程管理方法及装置 |
CN106959895A (zh) * | 2016-01-12 | 2017-07-18 | 阿里巴巴集团控股有限公司 | 快速释放线程的资源调度方法和系统 |
CN107305507A (zh) * | 2016-04-25 | 2017-10-31 | 北京京东尚科信息技术有限公司 | 死锁控制方法和装置 |
CN109669858A (zh) * | 2018-11-22 | 2019-04-23 | 新华三技术有限公司合肥分公司 | 程序死锁的测试方法、装置和设备 |
CN110008041A (zh) * | 2019-03-27 | 2019-07-12 | 北京奇艺世纪科技有限公司 | 一种消息处理方法及装置 |
CN111143065A (zh) * | 2019-12-25 | 2020-05-12 | 杭州安恒信息技术股份有限公司 | 一种数据处理方法、装置、设备及介质 |
-
2005
- 2005-08-20 CN CN 200510041587 patent/CN1917504A/zh active Pending
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102640113A (zh) * | 2009-12-04 | 2012-08-15 | 微软公司 | 针对分布式持久实例的锁定解决 |
CN102640113B (zh) * | 2009-12-04 | 2015-08-19 | 微软技术许可有限责任公司 | 用于解决两个或更多执行线程之间的锁定冲突的方法和系统 |
CN103176848A (zh) * | 2011-11-08 | 2013-06-26 | 辉达公司 | 计算工作分布参考计数器 |
CN103946827A (zh) * | 2011-11-22 | 2014-07-23 | 华为技术有限公司 | 用于实施内核和用户空间之间共享的锁的系统和方法 |
CN103946827B (zh) * | 2011-11-22 | 2017-02-22 | 华为技术有限公司 | 用于实施内核和用户空间之间共享的锁的系统和方法 |
CN103246552A (zh) * | 2012-02-14 | 2013-08-14 | 腾讯科技(深圳)有限公司 | 防止线程出现阻塞的方法和装置 |
CN103246552B (zh) * | 2012-02-14 | 2018-03-09 | 腾讯科技(深圳)有限公司 | 防止线程出现阻塞的方法和装置 |
CN102662747A (zh) * | 2012-04-23 | 2012-09-12 | 深圳市融创天下科技股份有限公司 | 一种线程访问临界区的方法、系统和终端设备 |
CN103678991A (zh) * | 2012-08-30 | 2014-03-26 | 想象力科技有限公司 | 多线程处理器中的全局寄存器保护 |
CN105138397A (zh) * | 2012-08-30 | 2015-12-09 | 想象力科技有限公司 | 多线程处理器中的全局寄存器保护 |
CN103678991B (zh) * | 2012-08-30 | 2016-03-09 | 想象力科技有限公司 | 多线程处理器中的全局寄存器保护 |
CN105138397B (zh) * | 2012-08-30 | 2019-08-30 | 美普思技术有限责任公司 | 多线程处理器中的全局寄存器保护 |
CN103064729A (zh) * | 2012-12-19 | 2013-04-24 | 上海西本网络科技有限公司 | 对共享资源的加锁、控制方法和装置 |
CN103473137B (zh) * | 2013-09-16 | 2017-04-12 | 东软集团股份有限公司 | 避免死锁的资源分配方法及系统 |
CN103473137A (zh) * | 2013-09-16 | 2013-12-25 | 东软集团股份有限公司 | 避免死锁的资源分配方法及系统 |
CN104702655A (zh) * | 2014-03-21 | 2015-06-10 | 杭州海康威视系统技术有限公司 | 云存储资源分配方法及其系统 |
CN104702655B (zh) * | 2014-03-21 | 2018-04-27 | 杭州海康威视系统技术有限公司 | 云存储资源分配方法及其系统 |
CN106959895A (zh) * | 2016-01-12 | 2017-07-18 | 阿里巴巴集团控股有限公司 | 快速释放线程的资源调度方法和系统 |
CN106959895B (zh) * | 2016-01-12 | 2021-01-01 | 创新先进技术有限公司 | 快速释放线程的资源调度方法和系统 |
CN105700939A (zh) * | 2016-04-21 | 2016-06-22 | 北京京东尚科信息技术有限公司 | 一种分布式系统中多线程同步的方法和系统 |
CN105700939B (zh) * | 2016-04-21 | 2019-07-02 | 北京京东尚科信息技术有限公司 | 一种分布式系统中多线程同步的方法和系统 |
CN107305507B (zh) * | 2016-04-25 | 2020-05-01 | 北京京东尚科信息技术有限公司 | 死锁控制方法和装置 |
CN107305507A (zh) * | 2016-04-25 | 2017-10-31 | 北京京东尚科信息技术有限公司 | 死锁控制方法和装置 |
CN106407016A (zh) * | 2016-10-19 | 2017-02-15 | 腾讯科技(深圳)有限公司 | 一种多线程争抢资源的模拟方法及装置 |
CN106407016B (zh) * | 2016-10-19 | 2021-06-25 | 腾讯科技(深圳)有限公司 | 一种多线程争抢资源的模拟方法及装置 |
CN106681809A (zh) * | 2016-12-05 | 2017-05-17 | 上海斐讯数据通信技术有限公司 | 一种基于锁的线程管理方法及装置 |
CN109669858A (zh) * | 2018-11-22 | 2019-04-23 | 新华三技术有限公司合肥分公司 | 程序死锁的测试方法、装置和设备 |
CN109669858B (zh) * | 2018-11-22 | 2022-04-12 | 新华三技术有限公司合肥分公司 | 程序死锁的测试方法、装置和设备 |
CN110008041A (zh) * | 2019-03-27 | 2019-07-12 | 北京奇艺世纪科技有限公司 | 一种消息处理方法及装置 |
CN110008041B (zh) * | 2019-03-27 | 2021-03-19 | 北京奇艺世纪科技有限公司 | 一种消息处理方法及装置 |
CN111143065A (zh) * | 2019-12-25 | 2020-05-12 | 杭州安恒信息技术股份有限公司 | 一种数据处理方法、装置、设备及介质 |
CN111143065B (zh) * | 2019-12-25 | 2023-08-22 | 杭州安恒信息技术股份有限公司 | 一种数据处理方法、装置、设备及介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1917504A (zh) | 一种避免资源数据共享访问导致死锁的加锁方法 | |
CN1174323C (zh) | 管理共享内存的方法 | |
CN1115644C (zh) | 利用相关数据库实现非循环定向图形结构的方法 | |
CN1783123A (zh) | 基于资源需求和业务影响的过程执行管理 | |
CN1220946C (zh) | 管理计算环境的分区组的方法和系统 | |
CN1838077A (zh) | 可调度性确定方法和实时系统 | |
CN1755617A (zh) | 实体域 | |
CN100337207C (zh) | 一种信号量死锁的检测方法 | |
CN1906586A (zh) | 用于在多处理器系统中处置处理错误的方法和设备 | |
CN1975679A (zh) | 用于优化分段资源分配的方法和设备 | |
CN1119764C (zh) | 关于数据库的方法 | |
CN1906600A (zh) | 计算实用工具的分级资源管理 | |
CN1908903A (zh) | 执行作业步的系统和方法以及计算机产品 | |
CN1906598A (zh) | 信息处理设备、存储区管理方法和计算机程序 | |
CN1828541A (zh) | Java操作系统中定时任务的实现方法 | |
CN1851693A (zh) | 一种对系统资源进行管理的实现方法 | |
CN1975676A (zh) | 多节点计算机系统和用于监视其性能的方法 | |
CN1848111A (zh) | 用于内存数据库的一种数据操作接口的实现方法 | |
CN1889045A (zh) | 多任务软件系统中并发事件的处理装置和方法 | |
CN1670705A (zh) | 一种对机群实现集中并发管理的方法 | |
CN1967500A (zh) | 自动测试过程中资源使用的方法 | |
CN1892615A (zh) | 带有虚地址空间属性的软件行为描述、获取与控制方法 | |
CN1928814A (zh) | 基于组织实体能力的软件过程建模方法和系统 | |
CN1770108A (zh) | 软件在线升级的方法 | |
CN1245685C (zh) | 基于构件的操作系统动态设备驱动的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20070221 |