CN1175341C

CN1175341C - 异步更新共享资源的接口***和方法

Info

Publication number: CN1175341C
Application number: CNB001047477A
Authority: CN
Inventors: St; S·T·马科特
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-03-25
Filing date: 2000-03-24
Publication date: 2004-11-10
Anticipated expiration: 2020-03-24
Also published as: JP2000284978A; TW498281B; SG97863A1; CA2292040A1; EP1039384A2; EP1039384A3; US6449614B1; JP4042945B2; CN1268688A; CA2292040C

Abstract

描述更新请求的数据结构，它可以排列在一个更新请求的等待队列中，该请求等待当前任务来执行，而不是当前正占用共享资源上的专门锁的调用任务。提供了其它队列，它排队从等待队列中删除但还未处理过的数据结构；请求的数据结构，请求解除或降级锁；请求的数据结构，该请求已经处理过且需要返回到空闲内存；请求的数据结构，该请求需被叫醒，或该请求描述锁不被占用时，将要运行的张贴处理流程。

Description

异步更新共享资源的接口***和方法

发明背景

本发明的技术领域

本发明涉及接口***和方法。更具体而言，它涉及一种***和方法，该***和方法用来管理容许异步更新共享资源的锁，而无需任务切换，等待或CPU空转。

背景技术

计算机***提供许多机制和方法用来防止更新内存中的数据结构和对象。典型的做法是更新驻留计算机内存的共享资源，同时占用独占锁(这样确保资源的原子更新)。这样的***一般要求需要存取数据结构和对象的任务等待更新数据结构和对象，直到独占锁被授权，因而经常需要暂停正在等待的任务，这种情况下可能引起***错误。

因此，技术上需要一种***和方法能消除或减少任务等待锁从而改进***性能。同样也需要若因这样或那样的原因任务不允许等待时，能容许对共享资源进行更新而不需要让任务等待独占锁。这样的任务在等锁的同时可以不被暂停，且不会对***导致某种错误。

本发明的目的是提供一个改进的管理锁的***和方法。

本发明的另一目的是提供一个能提高性能的管理锁的***和方法。

本发明的另一目的是提供一个管理锁的***和方法，可以避免正式的任务暂停或CPU空转。

本发明的另一目的是提供一个管理锁的***和方法，可以避免代价过高的锁冲突。

本发明的再一目的是提供一个同步和异步的管理锁的***和方法。

发明概述

依照本发明的***和方法，应用程序更新带独占锁的资源不需任务暂停或任务切换，其方式是代表第一任务选择性地排列更新请求等待执行，同时第二任务维持所需的锁。提高占用被请求锁的第二个任务有选择地排队代表第一个任务执行更新请求。

以下将对本发明的优选实施例详细描述并配以图解，本发明的其他性能和优点是显而易见的。

附图简介

图1是一个锁的示图。

图2表示图1中的锁的状态域。

图3表示依照本发明的最佳实施例的WAIT_ELEMENT的数据结构，定义在等待的工作。

图4表示函数数组的格式，该函数数组包括定义工作类型和任务类型的域，及指向函数地址的二维数组的指针。

图5是本发明的优选实施例的Lock_UpdateResource过程的流程图。

图6是宏过程MVS_update的流程图，用来处理这样一种情况，即被请求锁已被其它状态占用并不能由调入任务所用。

图7是例程lock_or_wait的流程图，应用要么获得所需状态的锁，要么在得不到时在LIFO等待队列中加一个等待项。

图8是例程MVS_unlock的流程图，用于任何时候当一任务试图释放某一锁同时发现等待队列中有等待项或这个锁状态将LOCKED位置于on时，调用该例程。

图9表示一用来排队任务等待项的全局队列。

图10表示一异步更新函数数组。

图11是过程do_wait的流程图，每次当一线程需进入等待锁时，执行该进程。

图12是例程add_to_global的流程图，该例程在全局队列中选择性地加上一个等待项。

图13是全局例程romove_from_global的流程图，该进程在全局队列中选择性地删除一个等待项。

图14是张贴处理例程return_wait的流程图，该例程选择性地将一个等待项返回空闲存储空间。

图15是例程quiesce_global的流程图，该例程用来停止全局队列。

图16表示aevents的占用队列的示图。

图17表示function_array的示图。

图18是例程queue_io的流程图。

图19是张贴处理例程issue_io的流程图。

图20是资源更新例程schedule_io的流程图。

图21是例程schedule_first_io的流程图。

图22表示请求的占用队列的示图。

图23表示空闲服务线程队列的示图。

图24表示客户线程的执行流程的示图。

图25是代表服务线程的执行流程的伪码。

图26是表示更新例程queue_request的流程图。

图27是表示更新例程post_service_thread的流程图。

图28是表示更新例程get_next_request的流程图。

图29是一个哈希表的示图。

图30表示LRU结构的队列的示图。

图31表示自由结构文件队列的示图。

图32是例程stkc_file_put的流程图。

图33是例程hash_put的流程图。

图34是例程file_put的流程图。

图35是例程file_postwork的流程图。

图36是几个队列和列表的高层***图，依照本发明的最佳实施例WAIT_ELEMENT有选择性地在这里移动，包括取得队列，解锁队列，返回队列，新建队列，等待队列和张贴队列。

实施本发明的最佳模式

依照本发明的优选实施例，提供了一种接口***和方法，它容许任务连续地以一种先到先得的方式，利用原子(atomically)自动地但不必同步地执行更新共享资源。这种接口***和方法以这样一种方式进行更新，即它不需要调用任务成为真正实施更新的任务。因此，可以根据调用任务异步地进行更新。

在大多数的标准加锁包中，等待加锁的任务是由一些数据结构代表并置于某种顺序的队列中。依照本发明的优选实施例，对代表调用任务的将进行的更新的描述进行排队，而不是如果所需锁被当前任务占用时，将调用任务置于等待状态。这意味着更新将根据调用任务异步进行，但调用任务从不需等待。而且，当前任务在它(当前占用着锁的任务)释放锁之前代表调用任务执行更新，因此能保证更新能利用原子，连续地，并以选到先得的方式进行。

依照本发明的另一实施例，增加了能够使用本发明的异步更新***和方法的应用程序的数目，这是与标准同步(现有技术)锁定工具合作而实现的。

计算机内存中的资源是由锁来保护的。典型的情况是该锁是3个计算机字。字节总数独立于硬件设备。例如，对IBM MVS操作***来说，一个3个字的锁需12个字节的存储空间。

应用程序通过下列函数调用对锁初始化：

Lock_Init(@_of_lock，Max_Queuing)

其中：

@_of_lock是保护资源的锁地址。

Max_Queuing是容许异步更新资源的排队的最大数量。若调用者

希望无限制地排队时，该值可以设定为一特殊值-1。

如前所述，本发明的优选实施例也支持标准(现有技术)锁定机制。例如，调用者能够取得一写或读模式锁，且若它不能通过下列调用立即得到锁，调用暂停：

lock_ObtainWrite(@_of_lock)

lock_ObtainRead(@_of_lock)

lock_ReleaseWrite(@_of_lock)

lock_ReleaseRead(@_of_lock)

其中：

@_of_lock是保护资源的锁地址。

依照本发明的优选实施例，为了容许异步更新模式，调用者指定被调用的执行不同更新的函数。例如，如果调用者想增或删链结列表，add_list和remove_list这二个函数将被定义成异步更新工具。数据结构越复杂，可以定义函数越多。

本发明的优选实施例的另一功能是，容许调用者定义不同类型的允许更新资源的***任务。因为是由一个不同类型的任务而不是调用任务来执行更新，这一点是很重要的，例如，在MVS中，有标准任务，也有由有不同编程环境的***需求块(SRB)代表的任务。另一实例出现在多语言应用程序中，在这种应用程序中任务运行来自不同编程语言的代码。这容许不同的任务对资源作出更新但不必运行完全一样的例程。例如，一个是运行C语言代码的增加链结列表操作与另一个运行汇编代码的操作不同，然而它们均要更新同一列表。还有，同后面实例中的方法所描述的一样，对于使用异步更新工具作为解决某一问题的任务作出分类，这可能是有用的。

本发明的优选实施例的接口的另一功能是，能使某一函数在对共享资源作出更新，且锁己被释放之后。这对减少锁冲突是必要的。当占用预时，基于资源状态更新资源可能需要额外的处理，但是执行这种处理并不需要同时占用锁。例如，删除链结列表可能需要在维持锁的同时，从链结列表中物理地删除某对象，然后将该对象返回至空闲存储空间。用这种在释放保护列表的锁之后将对象返回空闲存储空间的方法，减少了锁冲突。

本发明的优选实施例的另一功能包括，能指定锁工具将传递给更新例程的参数，也能在用作更新资源的函数和在当锁不被占用时执行张贴处理的函数之间传递信息。

异步更新工具接口结构

本发明的优选实施例的异步更新工具接口结构包括函数集，以及代表更新资源的可能类型的有关任务类型。这些函数和任务类型保存在一个含函数指针二维数组的结构中。每一函数被编号并代表一列。每一任务类型编好号代表数组中的某列。

分配某函数数组的例程有下列模板：

lock_allocate_function_array(work_types，task_types)

其中：

work_types是可能更新或处理被保护资源的不同的更新或张贴处理例程的编号。

task_types是对那些可能更新被保护资源的任务的不同定义任务类型编号。

lock_allocate_function_array例程返回含二维数组存储空间结构的地址。在一个链结列表实例中，只有一任务类型，work_types为3(代表增加，删除和返回空闲存储空间)，并且task_types为1。

用来定义锁工具的每个函数(不管该函数在占用锁时是否运行，还是在释放锁后运行张贴处理函数)有下列模板：

procedure<routine_name>(sync_flag，

task_type，

prc_arg1，

arg2)

其中：

routine_name是过程或函数名。

sync_flag是一标志，由锁工具传递给函数，表示它是否被发出更新请求的同一任务所调用。它的值或是TRUE，或是FALSE。

Task_type指示函数什么类型的任务在运行该函数的标志。因为可能异步执行资源更新，该更新函数可以根据某一不同定义的任务类型，而不是调用者的类型运行。

prc_arg1是首先返回码或参数编号为1。若该函数是一资源更新函数，即在在占用锁时运行的函数，那么prc_arg1是第一个由用户提供的参数。若它是一张贴处理例程，那么prc_arg1是由更新函数提供的返回值。这是一个机器字，在MVS中，它是4字节的信息，包含内存地址或一些其他相关值。

arg2，如果这是一个在占用锁时运行的资源更新函数时，它是第二个由用户提供的参数；如果它是一个张贴处理例程时，arg2是唯一由用户提供给流程的参数。

这些函数定义返回一个返回值并例如，作为一个机器硬件字来实现的。更新资源的函数(当占用资源锁时运行的函数)传递返回码prc_arg1给张贴处理函数(a.k.a.，例程)，该函数容许在资源更新函数和张贴处理函数之间传递信息。下面定义了一些特殊返回码：

WORK_NOPOSTWORK(-1)如果资源更新函数返回该返回值，张贴处理例程(若指定的话)将不被调用。这容许绕开张贴处理例程并将该函数调用所需的路径长度保存。

WORK_DONTUNLOCK(-2)执行完资源更新函数以后，这个返回码通知锁工具不要对资源解锁。一般而言，锁工具在执行完资源更新函数以后会释放锁。该返回码将让锁占用着(这意味着调用函数必须确保锁在某时获得释放)。该返回码容许资源更新调用函数使用嵌套锁，这也是本发明的优选实施例的一重要特征。更新资源时经常必须获得不只一个锁。使用该返回码容许在异步更新一共享资源前取得多个锁。后面的实例示范了该特性的使用，该特性对于嵌套异步锁定是必须的。

调用应用程序通过下列函数调用，指定每种类型的任务使用的函数：

lock_register_workunit(work_type，task_type，function，function_array)

其中：

work_type是程序员赋给这种更新类型的编号(0，1，…)。

task_type是赋给与本函数有关的任务类型的编号。

function是该函数的地址。

function_array是该函数将被加入的函数数组的地址。这是从lock_allocate_function_array返回的地址。

在一个链结列表实例中，程序员可选择给work_type赋值0来增加链结列表函数，赋值1来删除链结列表函数，赋值2来返回空闲存储空间函数。只有一个任务类型(0)。因此为了定义本链结列表实例的函数，对lock_register_workunit的函数调用需要三种调用。

为了使用本发明的优选实施例的接口结构，写了一段程序，它包括更新函数，单一一个对例程lock_allocate_function_array的调用，然后有N个对例程lock_register_workunit的调用，其中N是等于更新类型的数目乘以任务类型的数目。然后使用下列接口，反复地异步更新资源，直到程序中止，而不用任务暂停。

资源更新是通过下列接口完成的：

lock_UpdateResource(@_of_lock，@_of_functionarray，task_type，work_type，arg1，arg2，post_work，post_arg，rc)

其中：

@_of_lock是保护资源的锁地址。

@_of_functionarray是定义的函数数组的地址，该函数数组包括更新资源的集合。

tast_type是发出调用的任务的类型。

work_type是赋给将要执行的更新的编号(它与task_type一起指示用来更新资源的函数)。

arg1是第一个由用户提供的参数

arg2是第二个由用户提供的参数

post_work是赋给张贴处理例程的编号，该例程在更新函数(由work_type指定)之后的某时被调用，但不占用相关锁。如果需要一个张贴处理例程，调用者给NO_FUNCTION指定特殊值(-1)，意味着没有将要执行的张贴例程。

post_arg是用户提供给张贴处理例程的参数。

rc是该调用的返回码。这表示资源是由调用任务(没有锁冲突)同步更新，还是在调用者想知道该返回码的情况下，或在占用锁的当前任务上分配(同步)。

调用函数需要链接开销的一些路径长度。以下描述是快速路径接口，若锁是空闲时，该接口能锁住资源且让调用者顺序地更新；若锁不是空闲，异步调用该函数。对程序员来说工作加重，但能消除函数调用的链接开销，且在无锁冲突的情况下，容许异步更新并不比标准现有技术锁定传递的路径长度多。(当然当有锁冲突时，异步更新比同步更新过程处理冲突快得多)。

这些快速路径接口表示如下：

lock_Resource(@_of_lock，@_of_functionarray，task_type，work_type，arg1，arg2，post_work，post_arg，rc)

lock_Resource接口使用的参数同以上的lock_UpdateResource定义的一样，只多一个如下返回码：

WORK_INLINE，它意味着以独占模式获得锁，但因为没有与该锁发生争用，更新函数不运行。然后，调用者在该函数调用后顺序(in line)地更新资源。

unlock_Resource(@_of_lock，@_of_functionarray，task_type，post_work，post_arg，rc)

若锁无争用地被释放，unlock_Resource接口对资源解锁且返回WORK_INLINE。于是，调用者将顺序运行张贴处理码。不然，排队张贴处理工作以备另一任务去执行。

现在参考附图，本发明的异步更新资源工具的优先实施例，与同步资源更新工具联系起来一起描述。在这种情况下，将异步更新工具和同步更新工具结合起来，能提供更大的灵活性。这一点对本领域的技术人员来说是显而易见的，即不需提供同步资源更新就可以使用异步工具。

数据结构

参照图1，锁100由三个机器字定义，State 101，waitq 102，和maxqueued 103。在IBM MVS操作***中，每个字有四个字节。State101包括定义锁状态的状态位。Waitq是等待队列404(图36)，正在等待任务(在同步现有技术中，是锁等待者)的LIFO队列，或是资源更新(异步更新)的锚定位。Maxqueued 103在使异步更新调用等待前，指定容许的被排队的更新请求的最大个数。Maxqueued值为-1时表示无穷大。

参照图2，state 101包括一个32位的字，该字有E 121，W 122，L 123，P 124和R 125这五个值，其中域E 121中的一个位表示锁101是专门(写)占用的；域W 122中的一个位表示等待队列非空；域L 123中的一个位表示锁在较优先状态下被占用；域P 124中的一个位表示由于maxqueued的值已到或已超过。异步更新请求必须等待，而不是排队更新。域R 125包括占用锁的读锁者的数目。

参照图3，正在等待的工作由WAIT_ELEMENT数据结构105所定义，该数据结构包括next 106，prev 107，ecb 108，action 109，type110，workfun 111，workprc 112，workarg 113，workrc 114，funp 115，postwork 116和postarg 117等域。Next 106和prec 107，当保存在列表或队列中时，是WAIT_ELEMENT 105的向前和向后指针。在MVS操作***中，当正在让某任务等待时，Ecb 108是设为WAIT的字。Action 109有下列值之一：OBTAIONLOCK(1)，表示如果锁被另一任务所占有时，该任务想得到一个锁且将等待；RELEASELOCK(2)，表示该任务将释放一个锁；DOWNGRADE(3)表示该任务想降级锁；UPGRADE(4)表示该任务想更新锁且必要时将等待；WORKUNIT(5)表示WAIT_ELEMENT 105不是为某任务而是为资源排队工作。TYPE 110指定获得或释放锁的类型，即用EXCLUSIVE(x80000000)表示写模式和用READ(1)表示读模式。Workfun 111指定函数编号，即函数数组的索引，当占有锁去更新资源时运行该函数。Workprc112是资源更新例程的第一个函数参数。Workarg 113是资源更新例程的第二个函数参数。Workrc 114是资源更新例程的返回值。Funp115是函数数组130的一个指针，它是由lock_allocatate_function_array分配的结构。Postwork 116是张贴处理函数编号。Postarg 117是张贴处理参数。

参照图4，函数数组130表示work_type 131，task_types 132和arrayp133。Work_types 131指定函数数组中的更新函数的行的总数；Task_types 132指定函数数组中的任务类型列的总数；arrayp提供指向函数地址二维数组的指针或地址。

本发明的优选实施例使用IBM System/390比较和交换(CS)及二次比较和交换(CDS)硬件指令。在多处理器(MP)***中，这些指令以多处理器(MP)安全方式分别更新4或8个字节。执行在其他的硬件平台上使用相等的指令。这些指令从内存中取得一个旧值，一个新值，一个字或双字的地址：旧值与内存中的字(或双字)比较，如果它们相等，新值就保存在那里，否则指令失败。还有其它的可选择性的执行方案。所有这样的执行方案的共同特点是有能力排队WAIT_ELEMENT 105来要求更新函数被调用，因此，有助于执行更新和张贴处理例程。

参照图5，提出了lock_UpdateResource过程140。在步骤141中，调用CS指令来更新状态域使之从空(null)变成独占值。步骤142判断CS指令是否成功。若不成功的话，在步骤143中，调用MVS_update 160来处理争用。否则，在步骤144中，调用用来更新资源的例程(rc)，而且更新资源流程的返回码被保存。在步骤145中，使用CS指令来更新状态域101使之从独占值变成空(null)。步骤146中判断步骤145中的CS指令是否成功。若不成功的话，在步骤148中，调用MVS_update 190来处理争用。否则，在步骤判断是否指定了一个张贴处理例程。如果是的话，步骤149判断步骤144中保存的更新资源返回码是否等于WORK_NOPOSTWORK，如果不相等，在步骤150中调用张贴处理例程。

前面定义的快速路径宏lock_Resource和unlock_Resource的执行，与顺序宏lock_UpdateResource140的执行是相似的。

参照图6，MVS_update宏过程160处理这样一种情况，即在某些其他状态下锁已被占用，因此调用任务不能取得锁。取得与宏lock_UpdateResource相同的参数。在步骤161中，为WAIT_ELEMENT获得存储空间，然后与调用者指定的信息一起提交，如函数编号，任务类型，参数。在步骤162中，对lock_or_wait 175执行一次调用，要么向等待队列404加入WAIT_ELEMENT 105，要么得到独占锁。域ACTION 109设为WORKUNIT。步骤163判断lock_or_wait流程175是否排队WAIT_ELEMENT 105。如果否的话，在步骤164中，调用更新资源例程，保存返回码(rc)。在步骤165中，CS指令用来更新状态域101从独占值变为空(0)。步骤166判断CS指令是否成功，如果不成功的话，在步骤167中，调用MVS_unlock 190来处理争用。否则，步骤168判断是否指定了一个张贴处理例程，如果是的话，步骤169判断步骤164中的更新资源返回码(rc)是否设为WORK_NOPOSTWORK。如果否的话，步骤171调用张贴处理例程且传递更新步骤164的返回码(rc)。若步骤169中的返回码定为WORK_NOPOSTWORK，在步骤170中，返回WAIT_ELEMENT到空闲存储空间中。

参照图7，lock_or_wait流程175将要么取得所需状态的锁，要么以LIFO方式增加WAIT_ELEMENT 105到等待队列404中。

Lock_or_wait 175有下列原型：

lock_or_wait(@_of_lock，@_wait，type，action)

其中：

@_of_lock是锁地址。

@_wait是WAIT_ELEMENT结构的地址。

Type是获得的锁的类型(EXCLUSIVE，READ或LOCKED)。

action是OBTAINLOCK，RELEASELOCK，WORKUNIT等。

Type设为LOCKED表示比EXCLUSIVE高级的一种特殊状态，它防止任何其它任务更新状态域101。

在步骤176中，state域101和waitq域102分别保存在oldstate 423和oldqueue 424中。步骤177判断加锁位121是否在oldstate 423上。如果是的话，WAIT_ELEMENT 105被加到等待队列404的队首且存到newqueue 403中。在步骤181中，newstate 421设定为与oldstate 423相等，在步骤183中，等待位122在newstate 421上为开。在步骤184中，CDS命令用来更新在oldstate 423中的锁为newstate 412中的值。步骤185判断CDS命令是否成功，如果是的话，在步骤186中，返回指示被设定为指示WAIT_ELEMENT 105排队在等待队列404中。否则，处理返回步骤177。如果在步骤177，判断加锁位121在oldstate423上并未设置，那么步骤178判断在oldstate 423中的状态位101的基础上，能否获得所需状态的锁。如果不能的话，处理返回步骤179；否则，在步骤180中，基于oldstate 423和输入类型(这将是独占的)设置newstate 421，在步骤182中，newqueue 493设置为与oldqueue 424相等。处理将继续到步骤184，它将使用CDS命令，将锁从oldqueue 424更新成newqueue 403，且在步骤186返回WAIT_ELEMENT的状态被更新的指示。

一般地，通过lock_or_wait的循环要么在步骤179中增加WAIT_ELEMENT 105到等待队列404中，要么在步骤182更新锁状态域101为调用者所需的状态。步骤186返回它表明的指示。一般地，如果步骤177判断LOCKED位在状态域上，WAIT_ELEMENT必须排队。如果不在状态域上，那么调用者可以得到所需模式的锁，且在步骤178检查状态看在所需模式是否获得锁。例如，如果锁已锁定为读，那么想得到锁为EXCLUSIVE的任务必须排列WAIT_ELEMENT 105。

参照图8，当任务试图释放锁且发现有WAIT_ELEMENT在等待队列404中，或锁状态的LOCKED位为开时，MVS_unlock 190随时被调用。实际上大多数工作在解锁例程中，因为得解散队列WAIT_ELEMENT并处理它们。MVS_unlock原型如下：

MVS_unlock(@_of_lock，type，function array，task_type，post_work，prc，post_arg)

其中：

@_of_work是将被释放的锁的地址。

type是执行解锁的类型(EXCLUSIVE，DOWNGRADE，READ三者之一)。

function_array是包括与锁相关的资源函数的函数数组的地址。

task_type是发出调用的任务的类型。

post_work是张贴处理函数编号。

prc是资源更新例程的返回码。

post_arg是张贴处理函数参数。

MVS_unlock 190处理正常同步加锁和解锁，并且将在运行资源更新例程时占用的锁解锁。MVS_unlock 190循环重复直到完成处理为止。

参照图36，依照本发明的优选实施例，WAIT_ELEMENT 105选择性地在几个队列和列表中之间移动，包括取得队列400，解锁队列401，返回队列402，新建队列403，等待队列404和张贴队列405。如图所示，这些队列由TakenHead 410，TakenTail 411，unlockHead412，unlockTail，returnHead 414，returnTail 415，newTail 416，waitq102，postHead 417和postTail 418所锚定(anchored)。

取得队列400包括全部WAIT_ELEMENTs 105，MVS_unlock 190已从等待队列中取走它们但还没有处理。该队列400由TakenHead 410和takenTail 411双链接，因此可以从队首穿过到队尾(FIFO顺序)或从队尾穿过到队首(LIFO顺序)。

NewTail 416是一变量，它有从锁waitq域102取得的队列锚定的拷贝。NewTail 416是LIFO新列的队首。

解锁队列401，由unlockHead 412和unlockTail 413锚定，是一个解锁或降低请求的FIFO队列。

张贴队列405，由postHead 417和postTail 418锚定，是一个WAIT_ELEMENTS队列，它们代表正在等待唤醒的任务，或者它们描述当锁不被占用时将被运行的张贴处理例程。

返回队列402，由returnHead 414和returnTail 415锚定，是WAIT_ELEMENTS列表，它们被全部处理并需返回至空闲存储空间。

参照图8，在步骤中1，MVS_unlock 190给WAIT_ELEMENT取得内存，且根据类型(EXCLUSIVE，READ)和动作(RELEASELOCK或DOWNGRADE)对它初始化。

在步骤192，调用lock_or_wait 175取得在LOCKED状态的锁，或者根据动作增加WAIT_ELEMENT到等待队列404。

步骤193判断lock_or_wait 175是否排队WAIT_ELEMENT 105。如果否的话，在步骤194，takenHead 410和takenTail411被初始化为零(null)；在步骤195，WAIT_ELEMENT 105加到返回队列402，且returnHead 414和returnTail 415相应调整；在步骤196，锁被释放或降级到所需要的状态，且更新状态以反映锁被释放。在步骤197，锁状态和waitq锚102分别保存在oldstate 423和oldqueue 424中。

步骤198判断oldqueue是否空，如果否的话，在步骤199，设定newTail 416与oldqueue 424相等；在步骤201，newqueue 403设为空。在步骤204，设定newstate 423与oldstate 423相等；处理继续到下一步骤210。如果在步骤198判断oldqueue非空，那么在步骤200，newtail 416设为空；在步骤202，设定newqueue 403与takenTail 411相等。

步骤203判断takenTail 411是否为空，如果为空的话，在步骤206，设定newstate 421与oldstate 423相等；然后在步骤208，加锁位和等待位在newstate 421被关闭。处理继续到下一步骤209。如果步骤203判断takenTail非空，在步骤205，设定newstate 421与oldstate 423相等；在步骤207，在newstate中的上锁位被关闭；处理继续到步骤209。

在步骤209，关闭newstate中的保护位，处理继续到步骤210。在步骤210，调用CDS命令来设置锁状态和waitq 102，oldvalues等于oldstate，或oldqueue 424，和newvalues等于newstate 421或newqueue403。

步骤211判断CDS调用是否成功，如果不成功，处理返回步骤198。如果CDS调用成功，步骤212判断newtail 416是否为空，如果非空的话，步骤213处理在newqueue 403中的所有入口中循环，增加obtainlock和工作单元WAIT_ELEMENTS到获取队列400的队尾中，增加任何降级或释放锁请求到解锁队列401，且增加任何升级请求到获取队列400的队首。在该循环213中，在获取队列400中给请求的数目计数；而且在步骤214，如果请求的数目超过锁100的maxqueued 103，状态101的保护位124置为on，强迫工作单元同步运行。步骤215在解锁队列401中的所有入口循环，处理请求(该请求要么降级要么释放)，且更新锁状态101来反映释放或降级；处理过的入口(WAIT_ELEMENT)移到返回队列402。在步骤216，unlockHead设为空，且在步骤217，unlockTail设为空。步骤218判断保留位121和读锁者计数125在状态101中是否都为空；如果否的话，处理继续到下面步骤220；如果是的话，状态219在获取队列400中循环，来调用已在其排队的WAIT_ELEMENTS中指明的更新资源流程，并保存WAIT_ELEMENTS中的相关返回码，直到取得一个不是工作单元的WAIT_ELEMENT(却是一个锁的获得请求)；任何剩余的WAIT_ELEMENTS加到张贴处理队列405的队尾；如果更新流程返回WORK_DONTUNLOCK，该循环中止，且保留位121设在锁状态101，以确保锁保持占用给下一个异步锁请求备用。

步骤220在获取队列400中循环，如果指定的锁类型与在已排队的WAIT_ELEMENT中的锁的类型不冲突，该循环唤醒任何正在等待的任务；如果有冲突，循环结束。任何已处理的WAIT_ELEMENT加到张贴队列的队首，而且处理返回步骤197。

如果步骤212判断newTail非空，步骤221在张贴队列405中循环，它唤醒任何正在等待的任务，为锁等待者从张贴队列405中删除WAIT_ELEMENT，并且将它们加到返回队列402中。步骤222判断MVS_unlock 190是否与一个张贴处理例程一起调用(post_work不等于NO_FUNCTION)；如果否的话，处理例程继续到下面的步骤225；如果是的话，步骤223判断传给MVS_unlock的prc是否与WORK_NOPOSTWORK相等；如果是的话，处理继续到步骤225；如果否的话，在步骤224，作为输入传递给MVS_unlock的张贴处理例程被调用。

步骤225在张贴队列405中循环，如果有指定的例程而且更新资源函数不返回WORK_NOPOSTWORK，则为工作单元执行任何张贴处理例程，并将处理好的工作单元(WORK_ELEMENT)从张贴队列405移到返回队列402。步骤226将在返回队列402中的所有WAIT_ELEMENT返回到空闲存储空间中。

实例

本发明的优选实施例的异步更新工具可以应用到许多类型的资源和应用程序。特别适用于这样的情况，即资源需要被更新，但正在运行的任务并不需要等待更新的结果。在优选实施例中，赋予某任务使用异步更新函数或使用标准同步锁而获得同样资源的能力。这大大地扩展了可能性。

术语任务或线程用来说明计算机***中的工作单元。在IBM MVS操作***中，WAIT函数让任务等待，POST函数唤醒正在等待的任务。

实例一.维护锁等待者列表

如上所述，在优选实施例中，本发明的异步工具与同步锁工具合并在一起。

没有显示同步锁功能的设计，但在DFS/MVS环境中，锁工具使用低级MVS操作***工具让任务等待锁。DFX是一POSIX应用。如果DFS遇到程序意外，POSIX工具并非设计为处理在这些低级操作***功能(WAIT/POST)上等待的任务。因此，当程序意外发生时，DFS锁包不仅在锁本身上，而且在全局列表中排列WAIT_ELEMENTS，这些列表能用作检查，而且所有正在等待的任务能被唤醒并告知意外。

参照图9，当任务等待锁时，如上所述，它用lock_or_wait例程排队它的WAIT_ELEMENT到锁上，在等待前也将它的WAIT_ELEMENT加到全局列表或者队列230，也在任务等待后从全局列表中删除它。如果使用标准同步锁，争用全局列表230使得任务等待，因此，任何时候在需要等待单个锁时，任务有可能等待二次。这对性能来说是不希望发生的。

因此，使用本发明的优选实施例的异步更新工具，来增删全局列表230。要求运行的异步更新函数是add_to_global，它增加WAIT_ELEMENT 232，233，235到全局列表230；remove_from_global，它从全局列表删除WAIT_ELEMENT；return_wait，它将WAIT_ELEMENT返回到空闲存储空间中；和quiesce_global，它从全局列表230删除所有WAIT_ELEMENT，并唤醒等待者，设置保护标，因此不再容许更多的线程等待。全局列表230是一个由globalHead 231和globalTail 234锚定的双链接列表。

参照图10，定义的单个任务类型globalFuns 236生成一个4×1的异步更新函数数组237。

参照图11，每当一个线程需要进入等待锁状态时，执行do_wait240。步骤241执行过程：

lock_UpdateResource(&globalLock，globalFuns，ALL_TASKS，add_to_global，0，((int)waitp)，NO_FUNCTION，0，rc)；

步骤242等待ecb；且一旦收到它，步骤243执行过程：

lock_UpdateResource(&globalLock，globalFuns，ALL_TASKS，remove_from_global，0，((int)waitp)，return_wait，0，rc)；

在这种方式下，正在等待锁100的任务实际上只能在等待调用时暂停自己。在全局列表230中增加和删除任务(WAIT_ELEMENT)是在这样一种方式下进行的，即保证不让调用任务等待。在lock_UpdateResource 140的第一个调用241中，add_to_global例程245是更新例程，且waitp是WAIT_ELEMENT 105的地址，它传递给add_to_global例程245。不需张贴处理例程。在第二个调用243中，remove_from_global 250是这样的流程，它从全局列表230中删除入口(WAIT_ELEMENT 232，233或235中的一个)，return_wait是将WAIT_ELEMENT返回到空闲存储空间的张贴处理例程。

参照图12，add_to_global例程245(waitp＝arg)包括步骤246，该步骤判断保护标是否为空；如果是的话，步骤248设置一个错误码于被处理的WAIT_ELEMENT的ecb域108；如果否的话，步骤247增加WAIT_ELEMENT(在这种情况下，是任务232)到全局列表230的队首。

参照图13，remove_from_global流程250(waitp＝arg)包括步骤251，该步骤判断保护标124是否为空；如果是的话，返回码(rc)设为零；如果否的话，从全局列表230中删除WAIT_ELEMENT(即233)。在步骤254，返回码(rc)返回给调用者。

参照图14，return_wait流程260(waitp＝prc)包括步骤261，该步骤判断waitp是否为空；如果否的话，由waitp指向的WAIT_ELEMENT返回空闲存储空间。Return_wait 260是remove_from_global 250的张贴处理例程，remove_from_global通过它的返回码与WAIT_ELEMENT的地址联系，即作为prc输入给return_wait(自动地由资源更新工具)。return_wait 260将WAIT_ELEMENT返回给空闲存储空间。因为return_wait 260是张贴处理例程，当占用锁时，返回空闲存储空间并不执行。这表现了张贴处理例程的好处，从资源更新例程将返回值传递给张贴处理例程。

参照图15，quiesce_global 265唤醒所有的等待者，并用在步骤266中将保护标124设为1的方法，在步骤267告知它们：由于错误，程序正在中止。在步骤268，指针231和234清空，这样全局列表230为空。

实例2.管理占用队列的I/O设备

该实例涉及到1999年10月29号由S.T.Marcotte提交的美国专利申请(序列号09/240,719)所描述的***，该申请关于I/O服务命令发布I/O请求的应用影响的***和方法，受让人卷号EN998137上。Marcotte描述了一个I/O排队***，即，如果发布给设备的I/O的数目大于Max_Issued，Max_Issued是可调整的一个数目，它根据用这里描述的I/O驱动器的应用而调整，该***在排队延迟的I/O的设备上，有一在正在占用的队列。

参照图16，在该实例中，提供了aevents 272，273，275的一个占用队列270，它由holdHead 271和HoldTail 274所锚定，同时还有max_issued 287，current_issued 288和device_lock 289。Max_issued储存有发送给设备的I/O操作的最大数目，current_issued 288的储存有实际已发送给设备的I/O事件的数目。如果current_issued 288等于或大于max_issued 288，那么I/O操作(aevents)加到占用队列270中而不是直接发送给设备。当完成一个I/O，如果current_issued 288降到max_issued 287之下，I/O驱动器运行代码从占用队列270中取走第一个I/O(aevent 272)。

即使current_issued计数288超过max_issued计数287，这样调用的应用可以绕过占用队列270，因而给予应用程序对排队的几乎完全控制权。而且，即使current_issued 288超过max_issued 287，调用的应用程序后来能够从占用队列270中将I/O(aevents)移到设备上，这样容许调用的应用程序在已发出I/O之后重新排序I/O。

占用队列270，max_issued 287和current_issued 288可以使用本发明的优选实施例的异步资源更新工具，由锁来管理。在该***中，当在设备上完成I/Os，操作***(MVS)分配一称为SRB的特别任务，I/O驱动器用C代码编写且使用C任务，同时处理完成I/O的***SRB码由汇编编写且与C不同的执行环境。因此在这种解决方案中，定义了二种任务类型(C任务和SRB任务)，因而显示了具有多定义任务类型110的优势。I/O驱动器使用异步更新工具的任务来管理占用队列的I/O，而从不用暂停来获得同步锁。这样达到更好性能，且不需要暂停***I/O完成SRB。

一个aevent数据结构用来代表一个挂起的I/O。这种aevent数据结构描述了属于I/O操作的所有的相关信息，如果某任务需要在继续处理前等待I/O完成，它让一个ECB等待。因此任务可能必须等待I/O，但从不需等待更新I/O队列。在特定的实施例中，Max_issued设为2，提供最佳性能。提供的资源更新例程包括queue_io 280，issue_io290，schedule_io 300和schedule_first_io 310。它们将分别参照图18，19，20和21，随后详细描述。

queue_io 280是一个例程程，调用它来给I/O***引入新的I/O操作。如果调用者没有要求绕过队列或者current_issued 288小于max_issued 287，那么将I/O加入占用队列中。

issue_io 290是一张贴处理例程，它发送I/O给操作***设备。

schedule_io 300要么被调用来从占用队列270中将I/O移到设备上(不管current_issued 288或max_issued 287的值)，要么被调用来使用从占用队列270中删除I/O同时不发送I/O到设备的方法来取消I/O(aevent)。

schedule_first_io 310是一流程，当完成一个I/O(意味着只有一个I/O发送到设备)，而且根据current_issued和max_issued 287的值，从占用队列取走第一个I/O，该流程被调用。

参照图17，在本实例中，function_array 279是一4×2函数数组，4个更新类型(280，290，300和310)乘以2个任务类型(C任务或SRB)

一般地，当应用程序需要发送新I/O，它将发送下列异步资源更新调用：

lock_UpdateResource(&adevice->lock，ioFuns，CTASK，queue_io，0，ae，issue_io，ae，rc)；

其中ae是代表I/O操作的aevent结构的地址，该代码在C任务上运行，且张贴处理例程issue_io将发送I/O到设备上。

当应用程序想取消I/O，或想确保I/O在到设备的路径上，它使用下列调用(这容许应用程序使用从队列中间移去I/O的方法，来影响I/O的次序，例如)：

lock_UpdateResource(&devp->lock，ioFuns，CTASK，schedule_io，0，ae，issue_io，ae，rc)；

其中ae也是aevent结构的地址，代码运行在C任务上，且aevent作上标记是否需要取消(在这种情况下，I/O从不发送到设备)

当I/O完成时，***安排将检查占用队列的I/O的SRB，还可能安排第一个I/O到设备上(如上所述，根据max_issued 287和current_issued 288而定)。它使用下列调用：

lock_UpdateResource(&devp->lock，ioFuns，SRB，schedule_first_io，0，ae，issue_io，ae，rc)；

参照图18-21，对于本实施例，执行更新过程280，290，300和310。这可以用汇编和C版本对这四个流程编码到应用程序中方法来实现。因为这是异步的，或者调用C代码版本或者调用SRB编码来执行这些流程。

参照图18，queue_io流程280(ae＝arg)包括步骤281，在该步骤测试immediate位是否设在aevent中，或者current_issued 288是否小于max_issued 287。如果有一个为真，在步骤282，设置aevent中的busy位，表示aevent被发送到I/O设备；在步骤284，current_issued288增加；在步骤285，ae返回到调用应用程序。如果测试281不为真，步骤283，该aevent加到占用队列270的队尾；在步骤286，返回码WORK_NOPOSTWORK返回到调用者的应用。

因此queue_io 280仅仅更新队列270和/或current_issued计数288。实际上它不安排I/O(这花费许多路长(pathlength))，而是将aevent的地址传递给张贴处理例程issue_io 290。如果它仅仅增加一个I/O到占用队列270中，它用返回WORK_NOPOSTWORK的方法缩短了issue_io流程的回路。

参照图19，issue_io流程290(ae＝arg)是一个张贴处理例程。当占用锁时该流程并不运行，因此在设备队列上的锁争用大大减少了。步骤291判断cancel位是否设在该aevent中(即273)；如果是的话，在步骤292，I/O标记为完成带有取消错误；如果否的话，在步骤293中，调用操作***发送由该aevent代表的I/O到I/O设备上。

参照图20，schedule_io 300是一资源更新例程，它使用它的二个参数(aevent结构的地址ae和一个取消标prc，该标表示调用者要已取消的I/O而不是已发送的I/O)。如果I/O已经发送给设备，不用做任何事，但如果I/O没有发送给设备，它将从占用队列中删除，而且如果不希望取消的话，current_issued 288增加。如果没有I/O发送，issue_io 290也被绕过。步骤301判断busy位是否设置在ae指向的aevent(例如275)；如果是的话，不用做任何事，步骤308返回WORK_NOPOSTWORK；如果否的话，步骤302设置busy位；步骤303从占用队列270中删除aevent 275；步骤304判断cancel_flag是否为真。如果cancel_flag为真，步骤306设置在aevent结构275中的cancel位，步骤307返回ae给调用者；如果cancel_flag不为真，current_issued 288在返回ae之前增加。

参照图21，schedule_fisrt_io 310包括步骤311，它判断占用队列是否为空，或者current_issued 288是否大于max_issued 287。如果有一个条件为真的话，步骤313减少current_issued，步骤316返回WORK_NOPOSTWORK给调用者。如果二个条件都是假的话，步骤312从占用队列270中删除第一个aevent；步骤314设置在aevent结构中的busy位；步骤315返回已移走的aevent结构的地址给调用者。

例3.管理带异步锁的服务线程区域

参照图22至图28，存在着有限的任务区域，它能服务来自客户线程的工作请求，该工作必须因为这样或那样的原因(据应用程序而定)运行在服务线程上，而且请求将以先到先得的方式处理。在本实例中，客户线程可以要么等待请求完成，要么不等待请求完成(这意外着请求可以或是异步的或同步的)。可以有任何数目的客户或服务线程，这将据应用而定。具体地，例如，在IBM DFS/MVS产品中，用户任务调用DFS发出文件请求。由于各种各样的原因这些任务请求不能运行在调用的任务下，服务任务必须拾起用户文件请求并运行它。因此，存在一个服务线程有限区域，一定数目的用户任务(大约等于用户一次处理调用DFS的数目)需要分配到服务任务上。

在本实例中，定义了一个锁，提供了空闲服务线程328的列表326和客户请求323-325的请求队列320。请求队列由Qhead 321和Qtail322锚定，服务线程326由idle 327所锚定。每个服务结构328代表一个空闲服务任务，它也可以指向附属于那个服务任务的当前请求。

数据结构323包括与客户请求有关的信息，数据结构328代表一服务线程。一旦检查队列320且发现为空时，服务任务增加它的服务结构328到空闲列表326中。当一客户请求进入时，首先它检查空闲列表326，看看是否有一可用的服务线程328，如果没有的话，在请求队列320中排队该请求。更新队列320并不需要任何任务暂停或切换。在客户和服务线程之间有一任务切换，但那是需要的。对队列320更新并不需要任何任务暂停，不象现有技术方法那样将重负载的暂停锁加到队列上。

在本实例中，有二种类型的任务：客户任务和服务器任务。在这种情况下，象前面实例一样，提供的多任务使用的范围不限于不同的编程语言或执行环境，但实际异步更新流程需要它以确保正确的功能。实际上代码是相同的，所以尽管函数数组是3×2，在本实例中，二种类型的任务的函数(客户和服务)是相同的，这就是后面描述的过程并联系图24-28是怎样实现的。

资源更新例程如下：

queue_request 340：如果有一个可用的请求，由客户任务调用queue_request 340来分派该请求到服务线程328中，或者将该请求加到请求队列320中，。

post_service_thread 348：如果queue_request 340发现空闲服务线程，它叫醒正在睡眠的服务线程328。这是一个张贴处理例程，并不在加锁时运行，以使锁冲突最小化。

get_next_request 350：它删除在FIFO请求队列320中的最老的(第一个)请求323(假设请求加到队列的队尾)。该请求323将运行在服务线程完成处理请求之后，但在它返回睡眠之前(万一服务线程将发现在请求队列320上有更多的工作要运行)。请求323检查是否在调用的服务线程上异步运行以避免不需要的等待调用。

在本实例中有3个更新流程和2个任务类型，组成一个3×2的函数数组329来处理更新。

参照图24，客户线程的执行流程包括步骤330，获得该请求的内存；还有在步骤331执行以下过程：

lock_UpdateResource(&lock，qFuns，CLIENT，queue_request，0，request，post_service_thread，0，rc)；如果该客户线程想等待，那么在步骤332它等待request_ecb，一旦收到，就释放步骤330中为该请求而获得的内存。

参照图25，服务线程流程由步骤335的代码表示。服务线程328一直执行直到程序结束，而且运行基于包括该线程的服务块的地址的调用。步骤335包括：

Do forever：

Service->request＝0

Service->ecb＝0

Rc＝lock_UpdateResource(&lock，qFuns，SERVICE，

get_next_request，0，service，post_service_thread，0，rc)

If rc！＝WORK_SYNC OR service->request is 0

WAIT on service->ecb

<Process service->request>在步骤335的编码中，表现了lock UpdateResource返回码(rc)的重要性。如果get_next_request运行在调用线程上(服务任务)，那么它检查是否有请求；如果没有的话，它进入睡眠状态(WAIT)；否则，它执行请求。因为这是不需要的，所以减少了不必要的等待。

参照图26，更新流程queue_request 340(request＝arg)包括步骤341，它判断闲置列表328是否为空；如果是的话，在步骤343该请求325加到请求队列320的队尾；且在步骤346WORK_NOPOSTWORK返回给调用者。如果闲置列表328非空，在步骤342服务结构328从空闲列表326中删除；在步骤344该请求的地址保存到服务结构中；在步骤345被删除的服务结构的地址返回给调用者。总之，如果没有闲置服务线程328，该流程增加请求到请求队列320中，而且返回WORK_NOPOSTWORK，通知异步更新工具不要运行张贴处理例程。如果找到了一个闲置服务线程328，它将被删除，而且由异步更新工具调用张贴处理例程post_service_thread348。

参照图27，在步骤348，更新流程post_service_thread 348(service＝prc)将ecb传递给服务结构，来唤醒服务线程328。

参照图28，在步骤351，更新流程get_next_request 350(service＝arg)首先判断请求队列320是否为空。如果队列320为空，该服务结构加到空闲列表326，WORK_NOPOSTWORK返回给调用者。如果队列320非空，在步骤352从队列320中删除下一个请求；且在步骤354已删除的请求地址保存在服务结构中。步骤355判断sync.flag＝WORK_SYNC而且task_type＝SERVICE是否为真；如果为真，在步骤357，WORK_NOPOSTWORK返回给调用者；否则，在步骤356，返回服务结构的地址。使用异步更新功能，使用了自动传递给更新流程的二个参数sync_flag和task_type。Get_next_request 350代码检查它是否在服务线程上(非客户任务)运行着，如果是的话且它在同步运行，因为它将第一个请求从队列320取走，所以它绕过调用张贴处理例程post_service_thread 348。请求地址保存在服务结构中。服务线程检查lock_UpdateResource返回码，在这样情况下将看到工作同步完成，能避免不必须的等待调用(这是有些浪费的)。

总而言之，使用异步更新工具消除了更新闲置列表或者那种请求队列的等待，一旦争用在列表中发生，将有正式挂起(现有技术)以之保护那些列表。因为那些队列为每一个请求更新，争用发生相当频繁。

例四.返回对象到共享区域

最后一个实例示范使用将标准同步锁定与异步资源共享功能结合起来，来减少锁冲突和任务等锁的情况。

一般地，有这样一类问题，即存在某些类型资源的一些区域，而从该区域中要求取得对象的任务要取到它才能继续处理下去。在这种情况下，必须使用一种需要同步处理的正式的挂起类型锁。然而，当这样一个任务需要该对象时，不需要同步处理来将它返回到该区域中，因此能使用本发明的异步资源共享工具。在这样情形下，异步资源共享与标准锁定机制结合起来，能执行同步资源更新，以减少锁冲突和任务等待。

在DFS/MVS环境中，客户容许从DFS文件服务器中缓存文件状态和数据。它们是用取得代表缓存数据的权利的记号的方法来处理的。在DFS/MVS文件服务器中，有代码来缓存记号，每个文件可以有不只一个记号，且每个客户可以有不只一个有记号的文件。具体地说，DFS/MVS有给SMB客户的记号缓存，它有代表文件的结构和表示记号的结构。该文件结构保存在有大小限制的区域中，当所有文件结构当前都分配给文件时，用最近使用过的方案，使用LRU重用方案来重新分配文件结构给不同的文件。

参照图29-31，SMB记号缓存360有一哈希表361，用来基于文件标识符快速查找文件结构(stkc_file)362。它也有文件结构372的空闲列表370，它不用来分配给任何文件，还有文件结构366-368的LRU结构队列363，它刚刚分配，如果需要时能够再分配给另一个文件标识符。队列363由LRUqhead 364和LRUqtail 365锚定。

Stkc_file结构366，372代表文件，DFS中的文件由它们的标识符所表示(数值序列)。SMB标识缓存维护一个映射和文件缓存，每个Stkc_file结构366，372有一个给那些文件保留的记号的列表和代表当前查找文件的任务编号的域refcount。

哈希表361用来基于DFS文件标识符快速查找stkc_file。哈希表的每一行有一锁用来防止访问哈希表的行，而且有全局文件锁，用来更新域refcount，LRU队列363和空闲列表队列370。

这里不描述为给定的文件标识符查找(获得)Stkc_file结构366，372的代码，因为它使用同步锁定技术。这里描述表示具有Stkc_file结构的任务的异步代码。

每个任务查找Stkc_file时，Stkc_file的域refcount增加，而当每个任务完成查找文件时，它就减少。流程Stkc_file_put减refcount，它按下列程序执行：

IF refcount is now 0：

If there are tokens held for file Then

Add the file to the LRU queue

Else

Remove file form hash table and add it to free list。

如果缓存没有文件的记号，那没有理由为文件标识符缓存stkc_file。如果它确实有记号那只保留文件在LRU队列中，因为文件能分配给另外一个文件标识符。如果refcount不是0，那么有其它任务使用stkc_file，所以不做什么动作。因为这种处理可以更新哈希表361，包含stkc_file的队列的哈希表的行锁必须被锁定，且因为空闲队列370或LRU队列363可能被更新，所以文件锁必须占用。这样需要二个锁，本实例显示了本发明的异步更新工具的使用，它能获得所需的二个锁来更新资源，还能消除任务暂停的可能性。

只有一种任务类型(都是C任务)，但有二个函数数组。HashFuns只包括一个更新流程。

Hash_put 380是主流程，表示任务用stkc_file完成。这是外流程，当运行时只要将哈希表锁定。

File_put 385是内部流程，表示任务用stkc_file完成。当它运行时，哈希表和主文件锁的锁被占用。

File_postwork 395是用来释放哈希表行锁的例程。

特殊返回码WORK_DONTUNLOCK被hash_put用来保证一旦file_put例程385正在另一个线程异步运行，锁不被释放。File_postwork395用来确保释放哈希表行锁，以避免死锁。因此执行嵌套的异步锁定而不用任务暂停。

参照图32，stkc_file_put接收输入filep，filep代表放回原处的stkc_file的地址。在步骤376，stkc_file的文件id被混编处理以得到哈希行；保存位置编号。步骤377执行函数：

lock_UpdateResource(&hash_table[slot].lock，hashFuns，ALL_TASKS，hash_put，0，filep，NO_FUNCTION，0，rc)；首先判断文件包含在哪一个哈希表行，然后运行hash_put。

参照图33，在步骤381，hash_put(filep＝arg)380执行：

lock_UpdateResource(&filelock，fileFuns，ALL_TASKS，file_put，0，filep，file_postwork，0，rc)；

步骤382返回WORK_NOPOSTWORK。因此，hash_put给file_put(这暗示file_put运行同时占用文件锁)执行流程，并返回WORK_NOPOSTWORK，指示异步更新工具不要释放锁，因为file_postwork将这样做。在file_put运行在单独的任务上的情况下，这是必要的；如果发生这样的情况，那么当hash_put返回时，它必须保证锁仍然占用，给要运行file_put的其它任务备用。

参照图34，在步骤386，file_put(filep＝arg)例程385混编文件标识符且保存位置编号；步骤387减少文件的参考计数。步骤388判断文件的参考计数器现在是否为0，如果不是的话，步骤393返回哈希位置编号给调用者，并且退出。如果文件的参考计数现在不为0，步骤389判断记号是否给文件保留，如果是的话，步骤391将该文件加到LRU队列363的队尾。如果记号没有给文件保留，步骤390从hash行中删除该文件，并且步骤392将文件加到空闲列表370中。步骤393返回哈希位置编号且退出。

File_put流程385承担所有必要的工作。它也返回哈希位置编号，所以file_postwork 395知道释放哪个哈希行锁。当file_put 385在运行时，异步更新工具保证哈希行和文件锁都被独占占用。当file_put385返回前，释放文件锁。

参照图35，运行file_postwork(slot＝prc)395，同时不占用文件锁，在步骤396释放哈希表行锁。

总之，本实例示出了WORK_DONTUNLOCK返回码的必要，也示出了能够执行多么复杂的嵌套的异步资源更新例程。

实例5.跟踪表

跟踪表可以通过异步锁更新。当任务在做它们的工作时，它反复的更新跟踪表。如果跟踪表上的锁太重，表上的争用将很剧烈，性能也会降低。用本发明的异步资源更新工具，程序员可以设计跟踪工具，来给容许在跟踪表锁上的排队增加限制，以确保线程不会超载(若有的话，实际上很少发生)，这是用赋予Max_queued一个值给跟踪表的调用lock_init的方法来实现的。

相比现有技术的优点

本发明的一个优点是，提供了一个改进的管理锁的***和方法。

本发明的另一个优点是，提供了一个能提高性能的管理锁的***和方法。

本发明的另一个优点是，提供了一个管理锁的***和方法，能避免正式的任务挂起或CPU空转。

本发明的另一个优点是，提供了一个管理锁的***和方法，能避免代价过高的锁冲突。

本发明的另一个优点是，提供了一个同步和异步地管理锁的***和方法。

可选择的实施例

尽管为了示范的目的，在这里描述了本发明的特殊的实施例，但在不偏离本发明的精神和范畴下作出各种各样的修改，这是可以理解的。特别地，在本发明的范畴内，提供了程序存贮或内存设备，例如固定的或不固定的传送媒体，磁性的或光学的电线，磁带或光蝶，诸如此类，来储存能被机器读取的信号，根据本发明的方法和(或)部件与本发明一致的结构，以此控制计算机的操作。

而且，方法的每个步骤可以在任何通用计算机上执行，例如IBMsystem 390，AS/400，PC之类，而且追踪到一个或多个的程序模块或者对象，或者一个或多个的程序模块或者对象的某部分，它可以有任何编程语言生成，如C++，Java，Pl/1，Fortran或其它。更进一步，所说的每一步骤，可以实现在特别用途硬件上，或者为某用途而设计的电路模型中。

相应地，本发明的保护范围仅由下列权利要求或它们的等价物所限制。

Claims

1.一种使应用程序包括异步锁定工具的方法，它通过不用任务挂起或任务切换的锁定来更新资源，包括下列步骤：

排队由第一个任务发出的更新资源请求至该资源的锁；和

操作占用所述资源的所述锁的第二个任务，在释放所述锁前执行所述请求。

2.如权利要求1的方法，还包括下列步骤：

提供更新所述资源的二个或更多更新例程，包括第一个更新例程和其它更新例程；

在释放所述锁之前，所述第二个任务执行所述的第一个更新例程；和

在所述的第二个任务已释放所述锁之后，根据所述的第二个任务的返回状态有选择地执行所述的其它更新例程；从而减少锁争用。

3.如权利要求2的方法，还包括下列步骤：

从所述第二个任务传递返回码给所述的异步锁定工具。

4.如权利要求3的方法，所述返回码是work_nopostwork，用于绕过执行所述的其它更新例程。

5.如权利要求3的方法，所述返回码是work_dontunlock，用于合成嵌套异步锁。

6.如权利要求2的方法，还包括下列步骤：

指定多个任务类型来执行所述更新例程；

因此能选择性地应用多程序语言环境和多执行环境，和分割任务到逻辑分类中。

7.如权利要求2的方法，还包括下列步骤：

从所述应用程序传递一个或多个用户参数给所述更新例程。

8.如权利要求2的方法，还包括下列步骤：

从所述异步锁定工具传递参数sync_flag给执行所述请求的任务，所述参数指定所述任务是在调用线程上运行，还是在另一个线程上异步运行。

9.如权利要求6的方法，还包括下列步骤：

有选择性地传递参数task_type给执行所述更新例程的任务，所述参数task_type指定任务类型，所述任务正在以该类型运行。

10.如权利要求2的方法，还包括下列步骤：

有选择性地执行宏lock_resource或宏unlock_resource；

响应没有争用地获得或释放独占模式的锁，返回work_inline返回码，指导调用者有秩序地运行张贴处理代码。

11.如权利要求1的方法，还包括下列步骤：

响应应用程序提供的最大值，限制排队在所述锁上的异步更新请求的数目。

12.如权利要求1的方法，还包括下列步骤：

在多个任务的所述锁上，排队多个更新请求，由所述第二任务按已排队的次序连续执行。

13.一种能异步更新共享资源的接口***，包括：

多个数据结构，用于定义资源更新请求；和

一个等待队列单元，它排队数据结构，该数据结构描述当前任务，而不是调用任务等待执行的更新请求，它正在占用一个在所述共享资源上的独占锁。

14.如权利要求13的接口***，还包括：

一个取得队列单元，它排队从所述等待队列删除但还没有处理过的数据结构；

一个解锁队列单元，它排队请求解锁或降级锁的数据结构；

一个返回队列单元，它排队请求的数据结构，这些请求已处理且需要返回至空闲存储空间；

一个张贴队列单元，它排队请求的数据结构，这些请求需要被叫醒，或者描述将运行的张贴处理流程，同时所述锁不被占用。

15.如权利要求13的接口***，所述锁包括：

一个状态参数域，它存储定义所述锁的状态的状态位；

一个等待队列域，它锚定所述等待队列；和

一个最大的已排队域，它指定在异步更新调用等待之前容许的已排队的更新请求的最大值。

16.如权利要求13的接口***，所述锁的状态参数包括：

第一个标记(E)，它表示所述锁是否被独占；

第二个标记(W)，它表示所述等待队列是否为空；

第三个标记(L)，它表示所述锁是否在较优先状态下被占用；

第四个标记(P)，它表示是否已超过了容许的已排队的更新请求的最大值；

第五个标记(R)，它表示在所述锁上的所述更新请求的数目。

17.权利要求13的接口***，所述数据结构包括：

一个下一个域，它存有指向队列中的下一个数据结构的下一个指针；

一个上一个域，它存有指向队列中的前一个数据结构的上一个指针；

一个等待域，它指定所述数据结构是否代表使其等待的任务；

一个动作域，它指定所请求的动作，所述动作是获得锁，释放锁，降级锁，升级锁和工作单元中之一；

一个类型域，它指定获得或释放锁的类型；

一个工作函数域，它在函数数组中取得将运行的函数，同时占用锁来更新资源；

一个工作进程域，它存有所述资源更新例程的第一个函数参数；

一个工作参数域，它存有所述资源更新例程的第二个函数参数；

一个工作返回码域，它存有所述资源更新例程的返回值；

一个函数指针域，它存取函数组；

一个张贴工作域，它在所述函数组中确定一个张贴处理函数；

一个张贴参数域，它存有张贴处理参数。