CN101236509B

CN101236509B - 用于管理锁的系统和方法

Info

Publication number: CN101236509B
Application number: CN2008100045651A
Authority: CN
Inventors: K·S·亚当斯; M·J·洛朗克; D·L·奥西塞克
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2007-01-30
Filing date: 2008-01-22
Publication date: 2011-10-12
Anticipated expiration: 2028-01-22
Also published as: US7500037B2; CN101236509A; US20080184249A1

Abstract

在存在对锁的第一共享持有的条件下管理锁。存在对锁的第一独占持有的第一未决请求；对第一独占持有的第一未决请求在第一共享持有被授权之后作出。存在对锁的第二独占持有的第二未决请求；对第二独占持有的第二未决请求在对第一独占持有的第一未决请求之后作出。存在对第二共享持有的第三未决请求；对第二共享持有的第三未决请求在对第二独占持有的第二未决请求之后作出。第一程序指令响应于第一共享持有被释放而授权对独占持有的未决请求之一。第二程序指令响应于独占持有的释放而授权对第二共享持有的第三未决请求，该独占持有先前响应于对独占持有的一个请求而被授权。第三程序指令响应于第二共享持有被释放而授权对独占持有的请求中的另一个。

Description

用于管理锁的系统和方法

技术领域

本发明一般涉及计算机系统，并且特别涉及在计算机系统中管理可用于共享的和独占的所有权的锁。

背景技术

已知要提供锁以使得计算机程序或程序函数能够访问每个资源，该锁允许对例如数据结构、工作队列、设备、适配器、文件、数据库和目录的计算机资源的独占的和共享的持有。例如，计算机程序(在单一处理器或多处理器环境中执行)可以获得对文件的锁的独占持有以更新该文件。独占持有阻止任何其它程序在其正被更新时访问该文件，甚至是读取该文件。这阻止了其它程序访问该文件中的陈旧或不一致数据。然而，如果一个或多个程序只想读取文件(该文件当前未被独占地锁上)，则其可以全部同时获得对该锁的共享持有，以及同时读取(而非更新)该文件，因为这些程序中没有任何一个将改变数据。一些锁管理操作可以由内联(inline)扩展以生成代码的宏来执行。这种宏可以处理最通常的情况。其它锁管理操作可以由程序子程序来执行，其中，宏将剩余情况下的处理委托给该程序子程序。由此避免了通常情况下的子程序链接的开销。

在一些情况下，程序或程序函数中的执行线程通过循环或“旋转”而等待直到其请求的锁变得可用并且被授权。在这种情况下，锁被认为是“旋转锁”。在其它情况下，线程请求锁并且被推迟直到其被授权。在此期间，相同或其它程序或程序函数的其它线程可以在处理器上执行。典型地，当执行不同线程的单个计算机中存在多个处理器使用旋转锁，并且资源在被锁保护的同时在线程的非可先占部分中被访问。

例如，计算机中可以存在多个应用、单个操作系统和多个处理器。每个处理器拥有其自己的分配器函数和调度器函数，以及共享存储器中存在公共工作队列。在每个处理器上执行的分配器或调度器程序函数可能需要锁以访问公共工作队列。典型地，这种锁是旋转锁，并且分配器或调度器程序函数旋转以等待锁。在最简单的实现中，旋转锁不必以它们被请求的顺序而被授权。作为替代，它们是由首先碰巧发现该锁处于可用状态的任一处理器而获得的。然而，当存在在同一处理器上执行的多个不同程序(以时间共享的方式)时，每个程序通常请求推迟类型的锁。通常，对推迟类型锁的请求被排队并且当该锁变得可用时按照被请求的顺序而被授权。现有技术中已知的锁管理器释放功能通常从队列前端移除单个独占请求或一串连续的共享请求，以及当被其当前持有者释放时将锁授权给那些请求者。

当存在对于对锁的共享持有的多个有序/交错请求并且只要锁状态允许则对于共享持有的请求继续被授权时，已知类型的锁管理器出现问题。在此情况下，只要存在至少一个还未被释放的未决的共享持有，对于共享锁的请求就将继续被授权。在此期间，对于独占持有的请求将被延迟。例如，对于共享持有的第一请求在时刻“0”出现，以及该请求者持有该锁1秒钟。对于对同一锁的共享持有的第二请求在时刻“0.9”秒出现并且被授权，以及该请求者持有该锁1秒钟，即直到时刻“1.9”秒。对于对同一锁的共享持有的第三请求在时刻“1.7”出现并且被授权，以及该请求者持有该锁1.5秒钟，即直到时刻“3.2”秒。对于对同一锁的共享持有的第四请求在时刻“3.0”秒出现并且被授权，以及该请求者持有该锁1秒钟，即直到时刻“4.0”秒。在这种情况下，在时刻“0.5”秒作出的对于对同一锁的独占持有的请求将不被授权，直到一串重叠的共享持有被全部释放并且在此期间不存在对于共享持有的其它请求。这延长了锁对于独占持有不可用的时间。这个问题称为“活锁(livelock)”，并且可以甚至当对于独占持有的请求在对于对同一锁的共享持有的请求被接收(以及被授权)之前被接收到时“饿死”对于独占持有的请求。在前述实例中，在时刻“0.5”秒作出的对于独占持有的请求将不会被授权至少直到时刻“4.0”秒。

在过去，活锁问题已通过严格按到达时间排序锁请求并且先入先出地授权它们而得到解决。然而，在虚拟化环境中，这将导致低效率，因为下一个被授权给锁的处理器当该锁变得可用时不可以被基础管理程序分配，而其它处理器可以。这将导致所述已分配请求者在如果锁被授权则其可以立即使用该锁时继续旋转。

严格按到达时间排序锁请求的第二个问题是，如果独占和共享请求被交错，则将对于锁的共享持有的请求捆绑到一起时是低效的。作为实例，假设锁未被持有并且对于该锁的独占持有的请求在时刻“0”秒被作出并且被授权。同样假设所有锁持有者将持有该锁1秒钟。现在假设，在时刻“1.0”之前存在共享请求，其后是独占请求，其后是共享请求，其后是独占请求。在该实例中，严格排序的锁管理器在时刻“1.0”处理初始独占请求的释放并且授权持续1秒的共享持有。在时刻“2.0”，共享持有被释放并且独占持有被授权。在时刻“3.0”，独占持有被释放并且另一共享请求被授权。在时刻“4.0”，共享持有被释放并且独占请求被授权。以及最后，在时刻“5.0”，独占持有被释放。然而，如果在时刻“1.0”两个未决的共享请求被捆绑并且一起被授权，则接下来的独占请求仍然在时刻“2.0”被授权，但是第三独占请求将更早即在时刻“3.0”被授权，并且在时刻“4.0”释放独占持有，其提前一秒结束。因此，仅当共享请求在其间没有独占请求的情况下一个接一个到达时，严格排序的锁管理器才可以受益于捆绑共享请求。

当存在后随有对于该锁的共享持有的多个重叠请求的对于锁的独占持有的多个连续请求时，已知类型的锁管理器出现另一问题。在这种情况下，共享持有的多个请求者全部必须等待在前的对于独占持有的请求中的每一个都被满足。换句话说，可以至少部分上以重叠方式被满足的共享持有的许多请求者必须等待每个仅满足单个请求者的对于独占持有的每个请求。

以下锁授权算法也是已知的。根据该算法，对于对锁的独占持有的未决请求优先于对于对同一锁的共享持有的任何未决请求。当独占请求很少时，该算法是最优的，但当独占请求较多时会导致共享请求的长久等待。

因此，本发明的目的是减少请求者的平均等待时间，特别是当存在共享请求和独占请求的混合时。

发明内容

本发明在于一种用于在以下条件下管理锁的计算机系统。所述条件为：存在对锁的第一共享持有、存在对于对锁的第一独占持有的第一未决请求；对于所述第一独占持有的所述第一未决请求是在该第一共享持有被授权之后被作出的。存在对于对锁的第二独占持有的第二未决请求；对于所述第二独占持有的所述第二未决请求是在对于该第一独占持有的所述第一未决请求之后被作出的。存在对于第二共享持有的第三未决请求；对于所述第二共享持有的所述第三未决请求是在对于该第二独占持有的所述第二未决请求之后被作出的。其中，所述计算机系统包括：用于响应于所述第一共享持有被释放而授权对于独占持有的所述未决请求之一的装置；用于响应于所述独占持有的释放而授权对于所述第二共享持有的所述第三未决请求的装置，其中所述独占持有是先前响应于对于独占持有的所述一个请求而被授权的；以及用于响应于所述第二共享持有被释放而授权对于独占持有的所述请求中的另一个的装置。

根据本发明的特征，存在对于对锁的第三共享持有的第四请求；对于所述第三共享持有的所述第四请求是在对于所述第二共享持有的所述第三请求之后以及在独占持有的释放之前被作出的，其中，所述独占持有先前响应于对独占持有的一个请求而被授权。所述第二程序指令授权对所述第三共享持有的第四请求以与所述第二共享持有基本上同时地持有。

根据本发明的另一特征，存在对于对锁的第三共享持有的第四请求。对于所述第三共享持有的所述第四请求是在对于所述第二共享持有的所述第三请求之后以及在所述独占持有的释放之后被作出的，其中，所述独占持有先前响应于对独占持有的一个请求而被授权。第四程序指令在所述第二独占持有的释放之后授权对于所述第三共享持有的所述第四请求。

本发明还在于一种用于在以下条件下管理锁的方法，所述条件为：存在对锁的第一共享持有、对于对所述锁的第一独占持有的第一未决请求，对于所述第一独占持有的所述第一未决请求是在所述第一共享持有被授权之后被作出的，存在对于对所述锁的第二独占持有的第二未决请求，对于所述第二独占持有的所述第二未决请求是在对于所述第一独占持有的所述第一未决请求之后被作出的，存在对于第二共享持有的第三未决请求，对于所述第二共享持有的所述第三未决请求是在对于所述第二独占持有的所述第二未决请求之后被作出的，所述方法包括以下步骤：响应于所述第一共享持有被释放而授权对于独占持有的所述未决请求之一；响应于所述独占持有的释放而授权对于所述第二共享持有的所述第三未决请求，其中所述独占持有先前响应于对于独占持有的所述一个请求而被授权；以及响应于所述第二共享持有被释放而授权对于独占持有的所述请求中的另一个。

附图说明

图1是包括根据本发明的锁管理器程序、锁获取程序宏和锁释放程序宏的计算机系统的框图；

图2是在授权锁的独占持有过程中的图1的锁获取程序宏和锁管理器程序的流程图；

图3是在释放锁的独占持有过程中的图1的锁释放程序宏的流程图；

图4是在授权锁的共享持有过程中的图1的锁获取程序宏和锁管理器程序的流程图；

图5是在释放锁的共享持有过程中的图1的锁释放程序宏的流程图；

图6是在锁的独占持有改变为共享持有的过程中的图1的锁获取宏的流程图；

图7是在假设当前仅持有锁的一个共享的情况下、在尝试将锁的共享持有改变为独占持有的过程中的图1的锁获取宏的流程图。

具体实施方式

现在将参考附图详细描述本发明。图1示出了包括多个处理器(或 CPU)12a、b、c的计算机系统10，其中每个处理器都执行一个或多个程序。在所示的例子中，存在单个操作系统13和多个应用程序20、21和22，其全部由受该操作系统中的已知调度器程序函数23和已知分配器程序函数24控制的处理器12a、b、c执行。操作系统可以是例如用于非虚拟机环境的IBM z/OS操作系统、UNIX操作系统或Microsoft Windows操作系统，或者例如IBM z/VM管理程序、Xen管理程序或EMC VMWare管理程序的虚拟机管理程序。调度程序函数23在公共工作队列25上调度工作项以便执行，而分配器程序函数24将已调度的工作项分配给可用处理器。系统10还包括例如数据结构、工作队列、设备、适配器、文件、数据库或目录的已知类型的资源14，其可以用对相关锁的持有的相应类型以独占方式或共享方式访问。系统10还包括公共总线56和存储单元58上的已知RAM52和ROM 54。

系统10还包括根据本发明的锁管理器程序15、锁获取程序宏35和锁释放程序宏45。锁管理器15通过允许对锁29的独占持有或者对同一锁的一个或多个同时的共享持有而可以支持用于资源14的一个或多个锁29。在所说明的实施例中，请求者当等待其请求的锁时循环或旋转。(然而，当请求者不等待锁(即锁是推迟类型的)或通过除旋转之外的技术而等待时，本发明也是适用的。)对锁的持有被授权给处理器(在多处理器系统中)，其代表了当前在该处理器上执行的线程。

锁管理器程序15、锁获取宏35和锁释放宏45如下防止独占锁请求等待者的饿死并且减少请求的处理器和线程的平均等待时间。对锁的独占持有的请求和对同一锁的共享持有的请求根据情况按某种顺序到达。当对于锁的第一请求(可用于任一类型的锁请求)到达时，该请求被授权。为了说明，假设该第一请求是针对独占持有的。当持有者释放该独占持有时，如果存在对于该锁的共享持有的任何未决请求，则即使存在在先的对于同一锁的独占持有的等待请求，对于共享持有的未决请求也被全部准许被同时授权(当所述独占持有被释放时)。因此，当单个独占请求者连续接收和使用该锁的独占持有时，多个共享请求者不继续等待。此外，在等待所述独占持有被放弃期间，对于共享持有的多个请求可以到达并且当释放所述独占持有时全部以高度重叠的方式被同时处理。高度重叠处理最小化了下一个独占持有的等待时间。在释放共享持有之后，即使在持有当前共享时对于共享持有的额外请求已到达，也是另一独占持有被授权(假设存在对于另一独占持有的等待请求)。这防止了对于共享持有的一系列连续请求饿死对于独占持有的一个或多个请求。因此，当在放弃另一类型的持有时存在所述交替请求时，锁的授权在独占和共享持有之间交替。这最小化了总的平均等待时间，并且避免了对于独占持有的请求的饿死。下面详细描述前述锁管理器程序15、锁获取宏35和锁释放宏45的实现。

在下面参考图2-5描述的处理中，锁管理器程序15更新包括以下字段的锁管理数据结构或锁29：

“State”-锁的当前状态，即，“Av”是指锁当前可用于共享或独占拥有，“AvX”是指锁当前可用于仅独占拥有，“AvS”是指锁当前可用于仅共享拥有，“X”是指锁当前被独占拥有者持有，或“S”是指锁当前被一个或多个共享拥有者持有。

“Shcnt”-锁的共享持有者的计数或数量(仅当“state”＝S时有效，否则为零)。

“Xwcnt”-等待锁的独占持有的请求者(处理器)的计数或数量。

“Swcnt”-等待锁的共享持有的请求者(处理器)的计数或数量。

“Seq”或“Sequence”-每当独占持有被释放时被递增的编号。所述递增指示在假设存在共享请求者的情况下锁接下来将可用于共享持有。在下面描述的特定情况下，共享持有的请求者在次序编号上旋转直到其被递增；然后它们有资格接收锁的共享持有。

锁管理器程序15使用可用于独占的状态和可用于共享的状态来以交替方式授权各个独占请求以及捆绑并授权共享请求。进行该操作以便大量的连续/交错共享请求不能保持连续的锁的共享持有，以及因此不能无限期地饿死或阻塞对于锁的独占持有的请求(“活锁”)。这也防止大量共享请求过久地等待顺序授权和每个满足仅一个请求者的多个在先的顺序独占持有的释放。

由于这些限制，锁请求可以被不按顺序地授权，这因而实现了在虚拟化环境中对锁的更高效使用。

在下面说明的图2-7示出了根据本发明的用于管理锁的宏和程序子程序。一些锁管理操作由内联地扩展以生成代码的宏来执行。其它锁管理操作由程序子程序执行。在宏执行锁管理操作的情况下，避免了链接程序子程序的开销。在图2-7中，由程序子程序执行的步骤用虚线框住。

图2详细示出了由锁获取宏35和锁管理器程序15进行的处理。开始于步骤200，程序或程序函数(例如在处理器12a、b或c中的一个上执行的应用程序20、21或22、操作系统13的调度器23或分配器24)当该程序或程序函数需要对资源的独占持有时调用图2的处理并且调用锁获取宏35。作为响应，锁获取宏35假设锁在状态Av或AvX可用，并且自动地尝试将锁状态Av或AvX改变为X(步骤200)。如果锁状态为Av或AvX，即锁可用于任意类型的持有或独占持有，并且当锁状态在步骤200中被改变时不存在任何“干扰”(判定202，否分支)，则锁获取宏35在步骤200中成功地将独占持有授权给请求者，以及锁将被独占持有请求者持有(步骤212)。当在锁获取宏35执行步骤200和判定202时在另一处理器上执行的另一函数改变锁29的任何一个字段的状态时，发生“干扰”。在步骤202中，所述锁获取宏例如通过检查由尝试自动操作的比较和交换指令所产生的条件代码来确定步骤200中是否存在干扰。然而，如果在步骤200被执行时锁的状态不是Av和AvX，即锁当前不可用于所有类型的持有或独占持有，或者步骤200期间存在干扰(判定202，是分支)，则所述锁获取宏在步骤200中不能授权独占持有。在这种情况下，锁获取宏35调用锁管理器程序15，其中该锁管理器程序自动地递增等待锁的独占持有的请求者数量的计数(xwcnt)(步骤204)。接下来，锁管理器程序15确定步骤204期间是否存在阻止计数xwcnt的成功递增的干扰(判定206)。如果是这样(判定206，是分支)，则锁管理器程序15返回到步骤204以再次尝试递增等待锁的独占持有的请求者的计数。如果不是这样(判定 206，否分支)，则锁管理器程序15通过自动地尝试将锁状态Av或AvX改变为X并且递减等待锁的独占持有的请求者的计数来尝试授权锁的独占持有(步骤208)。如果当步骤208被执行时锁状态是Av或AvX，即锁可用于所有类型的持有或仅可用于锁的独占持有，以及当在步骤208中锁状态被改变且等待锁的独占持有的请求者的计数被递减时不存在任何“干扰”(判定210，否分支)，则锁管理器函数在步骤208中将锁的独占持有授权给请求者，并且锁将被独占请求者持有(步骤212)。如果锁的状态不是Av或AvX，即锁不可用于所有类型的持有或可用于仅独占持有，或者在步骤208期间存在干扰(判定210，是分支)，则锁管理器函数在步骤208中不能授权锁的独占持有。在所述情况下，锁管理器函数15返回到步骤208以再次尝试。锁管理器程序15将在步骤208和判定210上循环或旋转直到独占持有变为可用并且被授权。

图3示出了由锁释放宏45为释放依照图2的处理被授权的锁的独占持有所进行的处理。当之前请求和接收锁的独占持有的程序函数终止其对资源的访问时，开始于判定300，程序函数将调用锁释放宏45以释放独占持有。作为响应，锁释放宏45如下释放独占持有、相应地更新锁管理数据结构29以及确定接下来谁应当得到该锁。所述锁释放宏确定共享持有请求者的数量是否等于零(判定300)。如果是(判定300，是分支)，则不存在任何等待的共享持有请求者，以及因此不需要授权处于共享状态的下一持有。接下来，锁释放宏45自动地递增序号(用以指示独占持有已被释放)，并且尝试将锁的状态从X(被独占持有)改变为Av(可用于所有类型的持有)从而释放独占持有(步骤302)。这种自动更新还确认共享等待者的数量仍然为零。再次参考判定300，其中在(想要释放独占持有的)程序函数调用锁释放宏45时存在至少一个等待的共享持有请求者的否分支。在所述情况下，应当被授权的下一个持有是对于共享持有的请求。接下来，所述锁释放宏自动地递增序号(用以指示独占持有已被释放)，并且将锁的状态从X改变为AvS(步骤304)。这种自动更新还确认共享等待者的数量仍然非零。由于AvS状态，在所述或另一处理器上的锁获取宏35和锁管理器程序15接下来将授权共享持有给共享持有请求者而不管是否存在更早的对独占持有的等待请求。因此，假设当锁被释放时两种类型的请求都在等待，锁获取宏35的调用交替对共享和独占持有的授权。

在步骤302或304(依情况而定)之后，所述锁释放宏确定步骤302或304的自动更新是否成功(判定306)。如果所述更新成功(判定306，是分支)，则独占持有已被成功释放并且锁管理数据结构已被恰当地更新(条件308)。如果不是这样(判定306，否分支)，则所述锁释放宏确定所述更新的失败是否是因为锁没有处于独占持有状态(判定310)。如果是(判定310，是分支)，则调用所述锁释放宏来释放独占持有的程序函数并不拥有独占持有。这是一个错误(条件312)并且其终止处理。再次参考其中所述更新的处理由于除错误锁状态之外的原因而失败的判定310的否分支。在此情况下，所述故障必定是由于来自另一处理器的干扰。因此，所述锁释放宏返回到判定300以重复前述处理。

图4示出了由锁获取宏35和锁管理器程序15进行的用于为共享持有请求者获取锁的共享持有的处理。当在处理器12a、b、c中的一个上执行的程序函数需要共享持有时，开始于步骤400，其调用锁获取宏35。作为响应，如果以下三个条件之一被满足(并且该过程中不存在任何干扰)，则所述锁获取宏将在步骤400中立即授权共享持有：

(i)锁的当前状态可用于任何锁持有请求，即Av(在该情况下，所述锁获取宏将共享持有者的计数从零递增到一)，或者

(ii)锁的当前状态可用于共享持有，即AvS，以及不存在任何独占持有等待者(在该情况下，所述锁获取宏将共享锁持有者的计数从零递增到一)(因此，如果当前锁由于在先的一组共享等待者而可用于共享，并且存在正在等待的在先独占持有请求者，则所述锁获取宏将不授权该共享持有请求。在此情况下，仅已递增swcnt的那些在先的共享持有请求者被授权在此时接收锁的共享持有。这防止了等待的独占持有请求者的饿死。)，或者

(iii)锁的当前状态为S，并且不存在任何独占持有请求者(在该情况下，所述锁获取宏将递增共享锁持有者的计数)。(因此，如果当前锁状态为共享，以及存在正在等待的在先独占持有请求者，则所述锁获取宏将不授权另一共享持有。这防止了等待的独占持有请求者的饿死。)

如果用于授权共享持有的前述三个条件之一在步骤400中被满足，并且在步骤400的处理期间不存在对自动更新的任何干扰，则所述锁获取宏将在步骤400中将共享持有授权给当前请求者(条件403)。然而，如果用于授权共享持有的前述三个条件中没有任一个在步骤400中被满足或者在步骤400的处理期间存在干扰(判定402，否分支)，则所述锁获取宏调用锁管理器程序，其中所述锁管理器程序自动地取得锁的当前状态、独占持有等待者的计数和序号，并且递增共享持有等待者的计数(步骤404)。接下来，所述锁管理器程序确定在步骤404的处理期间是否存在干扰(判定406)。如果是(判定406，是分支)，则所述锁管理器程序返回到步骤404以再次尝试。如果不是(判定406，否分支)，则所述锁管理器程序确定在步骤404中所取得的锁状态是否为AvS和S以及是否存在任何独占持有等待者(判定410)。如果是(判定410，是分支)，则存在接下来被授权所述锁的独占持有等待者，即在所有当前持有者释放其共享持有之后。在所述情况下，所述锁管理器程序检查当前序号是否等于在步骤404中取得的序号。如果当前序号等于在步骤404中取得的序号(判定420，是分支)，则所述锁管理器程序旋转即返回到判定420以等待当前序号改变。这确保了这个共享请求不被授权直到当前或下一独占持有已被释放。如果当前序号不等于在步骤404中取得的序号(判定420，否分支)，则这意味着独占持有已刚刚被释放。在所述情况下，所述锁管理器程序检查锁当前是否可用于任意类型的持有或共享持有(判定422)。(其中锁的当前状态不是AvS或S或者不存在独占持有等待者的判定410的否分支也导致判定422。)如果锁当前并不可用于任意类型的持有或共享持有(判定422，否分支)，则所述锁管理器程序确定锁的状态是否为“S”，即锁当前以共享状态被持有(判定424)。如果不是这样(判定424，否分支)，则直到允许新的共享持有的三个状态即Av、AvS或S中的任一个出现之前，所述锁管理器程序旋转，即从判定422否分支跳转到判定424否分支以及返回判定422。如果锁在被发现处于状态S之前被发现处于状态Av或AvS(判定422，是分支)，则所述锁管理器程序自动地递增共享锁持有者的计数(shcnt)、递减等待得到共享持有的等待者的计数(swcnt)并且将锁的状态从其当前状态Av或AvS改变为S(步骤430)。然而，如果锁在被发现处于状态Av或AvS之前被发现处于状态S(判定424，是分支)，则所述锁管理器程序自动地递增共享锁持有者的计数(shcnt)以及递减等待得到共享持有的处理器的计数(swcnt)(步骤432)。(在这些条件下不需要将状态改变为S；状态已经是“S”。)在步骤430或432之后，依据情况而定，所述锁管理器程序确定联锁(interlocked)的更新是否由于在步骤430或432的处理期间改变了锁管理数据结构29中的任一字段而失败(判定434)。如果是(判定434，是分支)，则所述锁管理器程序返回到判定422以重复前述处理。然而，如果所述联锁的更新在判定434的否分支中被判定为成功，则请求的程序或处理器现在持有锁的共享(条件403)。

图5示出了由锁释放宏45进行的用于释放锁的共享持有的处理。开始于判定500，持有锁的共享并且想要释放它的程序函数调用锁释放宏。在判定500中，锁释放宏45确定共享锁持有者的当前计数“shcnt”是否等于零。如果是(判定500，是分支)，则该调用者正试图释放该调用者当前并不拥有的锁的共享，并且这是错误条件(步骤501)。然而，如果共享锁持有者的当前计数等于一(判定500，否分支，以及判定502，是分支)，即，该请求用于释放仅有的共享持有，则锁释放宏45确定当前是否存在任何独占持有的等待者(判定504)。如果不是这样(判定504，是分支)，则所述锁释放宏自动地将锁的状态设为Av，即可用于任何请求者，并且将共享锁持有者的计数递减到零以释放共享持有(步骤506)。再次参考判定504的否分支，其中存在至少一个独占持有的等待者。在所述情况下，独占持有的等待者被授权所述锁，并且所述锁释放宏自动地将锁状态设为AvX以指示该锁可用于独占持有者，并且将共享持有者的计数递减到零以释放锁的共享持有(步骤508)。再次参考判定502的否分支，其中存在除所述调用者之外的锁的其它共享持有者。在所述情况下，锁释放宏45将共享持有者的计数递减1，以释放被所述调用者持有的锁的共享而不是由其它持有者持有的共享(步骤510)。在步骤506、508或510(依情况而定)之后，所述锁释放宏确定在步骤506、508或510的执行期间是否存在干扰(判定512)。如果是这样(判定512，是分支)，则所述锁释放宏返回到判定500以重复前述步骤。如果不是这样(判定512，否分支)，则所述调用者的锁的共享持有已被成功释放(条件514)。

图6示出了由锁获取宏35进行的用于将锁的独占持有转换为共享持有而不在其间释放锁的处理。开始于判定600，拥有旋转锁的独占持有并且想要转换到共享持有的程序函数调用锁获取宏35。锁获取宏35在尝试改变锁状态之前确定锁状态是否当前为“X”，即锁当前以独占状态被持有(判定600)。如果不是这样(判定600，否分支)，则调用锁获取宏的程序函数并不拥有独占持有，并且这是终止处理的错误(条件602)。如果锁被独占持有(判定600，是分支)，则锁获取宏35自动地尝试将锁状态从“X”改变为“S”、将共享锁计数(shcnt)从零改变为一以及将序号递增一(步骤610)。如果自动更新由于来自另一处理器的干扰而失败(判定620，是分支)，则锁获取宏35返回到步骤600以重复前述步骤。如果不存在任何干扰(判定620，否分支)，则请求的程序函数现在持有锁的共享(条件630)。

图7示出了由锁获取宏35进行的用于尝试将被共享持有的锁转换为独占持有而不在其间释放锁的处理。开始于判定700，拥有旋转锁的共享持有并且想要转换到独占持有的程序函数调用锁获取宏35。在判定700中，锁获取宏35确定共享锁持有者的当前计数是否为零。如果是这样(判定700，是分支)，则请求者并不持有锁的共享并且这是终止处理的错误(条件702)。如果当前共享计数不为零(判定700，否分支)，则所述宏确定当前共享计数是否正好为一(判定710)，并且如果是这样的话是否存在独占请求等待(判定720)。如果共享计数大于一(判定710，否分支)或存在至少一个等待被满足的独占持有请求(判定720，否分支)，则至独占持有的转换不能进行并且处理被终止(条件712)。如果共享计数正好为一(判定710，是分支)以及不存在独占持有请求等待(判定720，是分支)，则锁通过将状态从“S”自动改变为“X”并且将共享计数从一自动改变为零而从共享持有转换到独占持有(步骤725)。在步骤725之后，所述锁获取宏确定在步骤725的执行期间是否存在来自另一处理器的干扰。如果是这样(判定740，是分支)，则所述宏返回到判定700以重复前述步骤。如果没有任何干扰出现(判定740，否分支)，则所述锁获取宏已成功释放了锁的共享持有并授权了独占持有而不使得该锁在其间可用于其它请求者(条件745)。

下面的实例说明了本发明如何通过不允许在对于独占持有的请求之后而在当前共享持有被授权的期间作出对于共享持有的请求、来防止独占持有请求者由于一系列共享持有请求而被饿死。独占请求者作出对于独占持有的请求，并且该请求按照图2被处理。在本实例中，独占持有由于锁被一个或多个共享持有者持有而当前不可用，因此所述锁获取宏在步骤200中未能提供独占持有，并且判定202由于锁状态不可用于任何持有Av且不可用于独占持有AvX而采取是分支。因此，锁管理器程序45接下来在步骤204中递增独占等待者的计数(xwcnt)。在无干扰地完成步骤204之后(判定206，否分支)，锁管理器程序45在步骤208和判定210上旋转直到锁变得可用于独占持有，即在判定210中锁状态等于Av或AvX。接下来，另一共享请求在对于独占持有的前一请求之后到达第二处理器，并且处理按照图4进行。根据本发明，该另一共享请求在对于独占持有的前一请求被授权并被释放之前将不被授权，即使该另一共享请求是在另一处理器拥有对同一锁的共享持有并且可以与该另一共享请求共享资源的时候到达的。在步骤400中，用于授权共享持有的三个条件中没有一个被满足，即(i)当前状态不是Av，(ii)当前状态不是AvS，以及(iii)虽然当前状态是S，但独占等待者的当前计数“xwcnt”非零。因此，所述锁获取宏将不把共享持有授权给当前共享请求者。由于下面的原因，锁管理器程序15也将不把共享持有授权给当前共享请求者。在步骤404中，所述锁管理器程序自动地取得序号并且递增共享等待者的计数(swcnt)。当步骤404无干扰地被完成时，所述锁管理器程序在判定410中确定当前状态等于S(即锁被至少一个共享拥有者持有)并且独占等待者的当前计数大于零(判定410，是分支)。因此，所述锁管理器程序确定从步骤404起是否已存在序号的改变，即从步骤404起独占持有已被授权和释放(判定420)。在该情况下，当前序号等于在步骤404中取得的序号(判定420，是分支)。因此，该新的共享等待者在判定420上不断循环或旋转，直到对于独占持有的当前请求被授权并且该持有被释放从而导致序号被递增(步骤302或304，图3)。因此，直到对于独占持有的在先请求被授权以及该持有被释放之前，对于共享持有的当前请求者将不被授权共享持有。这防止了“活锁”，即独占持有请求者由于交错顺序的共享持有请求而被饿死。

下面的例子是锁持有请求、授权和释放(下一事件Nn)的序列以及其对锁状态(Sn+1)的影响、锁的拥有、等待独占持有的请求者的计数(xwcnt)、等待共享持有的请求者的计数(swcnt)以及序号(即被释放的独占持有的编号)。在本例子中，在多处理器计算机中存在七个处理器(标识为处理器一至处理器七)。在本例子中，存在七个程序函数，其当分别在七个处理器上执行时请求持有。因此，对程序函数之一的持有授权被看作是对执行该程序函数的处理器的持有授权。

实例

状态S1：锁可用于所有类型的锁授权，即状态Av。不存在针对共享持有或独占持有的等待者。序号的值为十二。

下一事件N1：处理器一、二和三请求并且被授权共享持有。

状态S2：锁具有状态S以及被三个共享锁持有者处理器一、二和三持有。

不存在针对共享持有的等待者以及不存在针对独占持有的等待者。

下一事件N2：处理器七请求独占持有并且旋转以等待它。

状态S3：锁具有状态S并且仍然被所述三个共享锁持有者即处理器一、二和三持有，这是因为共享锁持有者中没有任何一个已释放其共享持有，并且独占持有请求还未被授权。不存在针对共享持有的等待者并且存在一个针对独占持有的等待者。

下一事件N3：处理器四请求独占持有并且旋转以等待它。

状态S4：锁具有状态S并且仍然被三个共享锁持有者即处理器一、二和三持有，这是因为所述共享持有者中没有任何一个已释放其共享持有，并且也没有独占持有请求已被授权。不存在针对共享持有的等待者并且存在两个针对独占持有的等待者。

下一事件N4：处理器五在观测到序号十二后请求共享持有并且旋转以等待它。即使锁当前处于共享状态，处理器五也不被授权共享持有，这是因为处理器五在至少一个对于独占持有的等待请求被作出之后才作出其对于共享持有的请求。这避免了处理器七和四的饿死。

状态S5：锁具有状态S并且仍然被三个共享锁持有者即处理器一、二和三持有，这是因为所述共享持有者中没有任何一个已释放其共享持有，并且也没有独占持有请求已被授权。存在一个针对共享持有的等待者以及两个针对独占持有的等待者。

下一事件N5：处理器六在观测到序号十二之后请求共享持有并且旋转以等待它。处理器六不被授权共享持有，这是因为处理器六在至少一个对于独占持有的等待请求被作出之后才作出其对于共享持有的请求。这避免了处理器七和四的饿死。

状态S6：锁具有状态S并且仍然被三个共享锁持有者即处理器一、二和三持有，这是因为所述共享锁持有者中没有任何一个已释放其锁的共享，并且也没有独占持有请求已被授权。存在两个针对共享持有的等待者以及两个针对独占持有的等待者。

下一事件N6：所有三个处理器一、二和三都释放其共享持有。

状态S7：锁的状态改变为AvX，即可用于独占持有。还没有任何独占锁请求已被授权(尽管这即将到来)。存在两个针对共享持有的等待者并且这时存在两个针对独占持有的等待者。

下一事件N7：处理器四正好在处理七之前获得独占持有。(在独占持有等待者之间不施加任何排序。)

状态S8：锁具有状态X并且被处理器四独占持有。存在两个针对共享持有的等待者和一个针对独占持有的等待者。

下一事件N8：处理器一在观测到序号十二之后请求另一共享持有并且旋转以等待它。

状态S9：锁具有状态X并且被处理器四独占持有。存在三个针对共享持有的等待者和一个针对独占持有的等待者。

下一事件N9：处理器四释放其独占持有。

状态S10：锁的状态变为AvS，即可用于一个或多个共享持有。即使请求独占持有的处理器七已比请求共享持有的处理器五等待更久，根据本发明，对于共享持有的等待请求也具有优先权。还没有任何共享持有已被授权(尽管这即将到来)。存在一个针对独占持有的等待者并且这时存在三个针对共享持有的等待者。序号已被递增为十三以反映处理器四对独占持有的释放。

下一事件N10：处理器二在观测到序号13后请求共享持有并旋转以等待它。

状态S11：锁的状态仍然是AvS，因为新近可用的锁还未被授权给任何等待的共享请求者。现在存在四个等待共享持有的请求者和一个针对独占持有的等待者。

下一事件N11：处理器一、五和六被授予锁的共享持有。

状态S12：锁的状态已被变为S以指示锁当前以共享状态被持有。当前存在三个共享锁的持有者，即处理器一、五和六，并且共享等待者的计数已被递减到一。由于处理器二在存在独占等待者时作出其请求，因此处理器二还未被与处理器一、五和六同时地授权共享持有，并且序号还未被从处理器二观测到的值十三改变。当前存在一个针对共享持有的等待者和一个针对独占持有的等待者。

(状态S10-S12说明了在下一独占持有被释放之前作出的共享请求如何被捆绑即同时授权，并且这是基于序号的。初期，当序号为十二时，处理器五、六和一关于锁旋转，这是因为锁已被处理器四独占持有。接着很快地，处理器四释放锁(将序号递增到十三)，然后处理器二请求共享持有。此时，存在四个共享请求和一个独占请求等待。接下来，观测到序号十二的处理器五、六和一的三个共享请求被授权，但观测到序号十三的处理器二没有被授权共享，因为仍然存在未决的独占请求并且序号还未改变。)

下一事件N12：处理器一、五和六释放其锁的共享持有。

状态S13：锁的状态现在为AvX，即可用于独占持有。由于之前被授权的持有处于共享状态并且存在针对独占持有的等待请求者，因此锁现在可用于独占持有。还存在针对共享持有的等待请求。

下一事件N13：处理器七被授权独占持有。

状态S14：锁的状态已变为X，以指示锁当前被(处理器七)独占地持有，并且独占持有的等待者的计数已被递减到零。存在一个针对共享持有的等待者。

下一事件N14：处理器七释放其独占持有。

状态S15：由于存在针对共享持有的等待者(以及最后一个被授权的持有是独占持有)，因此锁的状态已改变为AvS，即可用于共享状态。同样，序号已被递增到十四以反映处理器七对独占持有的释放。不存在针对独占持有的等待者，并且存在一个针对共享持有的等待者。

下一事件N15：处理器二被授权共享持有。

状态S16：锁具有状态S并且被一个共享锁持有者即处理器二持有。由于针对共享持有的唯一等待的请求者刚刚被授权共享持有，因此针对共享持有的等待请求者的计数已被递减到零。不存在针对独占持有的等待者。

下一事件N16：处理器二释放其共享持有。

状态S17：锁的状态被改变为Av，即可用于任意类型的锁持有。即使前一被授权的持有是共享的，该可用状态也不限于可用于独占持有，这是因为不存在针对独占持有的等待请求者。同样，不存在针对共享持有的等待者。

锁管理器程序15、锁获取程序宏35和锁释放程序宏45可以从例如磁盘或磁带、光介质、DVD、半导体存储器、存储棒等的计算机可读介质57被加载到计算机10中，或者经由TCP/IP适配器卡61从互联网59下载。

基于前述内容，已经公开了用于管理锁的系统、方法和程序。然而，在不偏离本发明范围的情况下可以作出许多修改和替代。例如，锁管理结构也可以包括这样的字段：其标识了独占持有情况下的锁的唯一拥有者或者共享持有情况下的锁的一个或多个拥有者。每个拥有者的标识可以是程序名、程序函数名、程序或程序函数的行号和/或当前执行当前拥有锁的程序或程序函数的处理器的名称(在多处理器环境中)。这个附加信息可以用于验证对于释放锁的持有的请求并且有助于问题诊断。

同样，尽管这里已经就旋转锁说明了本发明，然而本发明同样可以很好地应用于推迟锁。如在现有技术中已知的，用于推迟锁的锁管理数据结构典型地包括用于“推迟”未决请求队列的锚(anchor)，其中所述未决请求被先入先出地授权。现有技术中已知的锁管理器释放函数典型地从队列前端移除单个独占请求或一串连续的共享请求，并且当被其当前持有者释放时将锁授权给那些请求者。根据本发明，如下文所述，提供了用于部分地基于被释放的持有的类型而授权锁的持有的软件和/或硬件。如果当前持有是共享模式，当最后一个共享持有被释放时，如果推迟队列不为空，则第一个被排队的请求必须是独占请求，这终止了刚刚被满足的共享请求的捆绑。相反，如果被释放的持有是独占持有，则推迟队列被扫描并且当前在队列中的所有共享请求(即，在当前独占请求被释放之前所作出的所有请求)从队列被移除并且被同时授权。如果队列仍然非空(即，存在一个或多个被排队的独占请求)，则任何随后到达的共享请求将在现在位于队列首部的独占请求的授权和释放之后被排队且在下一组共享请求中被授权。

因此，已经作为说明而非限制公开了本发明，并且应当参考下面的权利要求来确定本发明的范围。

Claims

1.一种用于在以下条件下管理锁的计算机系统，所述条件为：存在对锁的第一共享持有、对于对所述锁的第一独占持有的第一未决请求，对于所述第一独占持有的所述第一未决请求是在所述第一共享持有被授权之后被作出的，存在对于对所述锁的第二独占持有的第二未决请求，对于所述第二独占持有的所述第二未决请求是在对于所述第一独占持有的所述第一未决请求之后被作出的，存在对于第二共享持有的第三未决请求，对于所述第二共享持有的所述第三未决请求是在对于所述第二独占持有的所述第二未决请求之后被作出的，其中，所述计算机系统包括：

用于响应于所述第一共享持有被释放而授权对于独占持有的所述未决请求之一的装置；

用于响应于所述独占持有的释放而授权对于所述第二共享持有的所述第三未决请求的装置，其中所述独占持有是先前响应于对于独占持有的所述一个请求而被授权的；以及

用于响应于所述第二共享持有被释放而授权对于独占持有的所述请求中的另一个的装置。

2.根据权利要求1的计算机系统，其中，存在对于对所述锁的第三共享持有的第四请求，对于所述第三共享持有的所述第四请求是在对于所述第二共享持有的所述第三请求之后以及在所述独占持有的释放之前被作出的，其中所述独占持有是先前响应于对于独占持有的所述一个请求而被授权的；并且所述计算机系统还包括用于授权对于所述第三共享持有的所述第四请求以与所述第二共享持有基本上同时地持有的装置。

3.根据权利要求1的计算机系统，其中，存在对于对所述锁的第三共享持有的第四请求，对于所述第三共享持有的所述第四请求是在对于所述第二共享持有的所述第三请求之后以及在所述独占持有的释放之后被作出的，其中所述独占持有是先前响应于对于独占持有的所述一个请求而被授权的；并且所述计算机系统还包括用于在所述第二独占持有的释放之后授权对于所述第三共享持有的所述第四请求的装置。

4.一种用于在以下条件下管理锁的方法，所述条件为：存在对锁的第一共享持有、对于对所述锁的第一独占持有的第一未决请求，对于所述第一独占持有的所述第一未决请求是在所述第一共享持有被授权之后被作出的，存在对于对所述锁的第二独占持有的第二未决请求，对于所述第二独占持有的所述第二未决请求是在对于所述第一独占持有的所述第一未决请求之后被作出的，存在对于第二共享持有的第三未决请求，对于所述第二共享持有的所述第三未决请求是在对于所述第二独占持有的所述第二未决请求之后被作出的，所述方法包括以下步骤：

响应于所述第一共享持有被释放而授权对于独占持有的所述未决请求之一；

响应于所述独占持有的释放而授权对于所述第二共享持有的所述第三未决请求，其中所述独占持有先前响应于对于独占持有的所述一个请求而被授权；以及

响应于所述第二共享持有被释放而授权对于独占持有的所述请求中的另一个。

5.根据权利要求4的方法，其中，存在对于对所述锁的第三共享持有的第四请求，对于所述第三共享持有的所述第四请求是在对于所述第二共享持有的所述第三请求之后以及在所述独占持有的释放之前被作出的，其中所述独占持有是先前响应于对于独占持有的所述一个请求而被授权的；并且所述方法还包括这一步骤：授权对于所述第三共享持有的所述第四请求以与所述第二共享持有基本上同时地持有。

6.根据权利要求4的方法，其中，存在对于对所述锁的第三