CA2138625A1 - Method and system for managing ownership of a released synchronization mechanism - Google Patents
Method and system for managing ownership of a released synchronization mechanismInfo
- Publication number
- CA2138625A1 CA2138625A1 CA002138625A CA2138625A CA2138625A1 CA 2138625 A1 CA2138625 A1 CA 2138625A1 CA 002138625 A CA002138625 A CA 002138625A CA 2138625 A CA2138625 A CA 2138625A CA 2138625 A1 CA2138625 A1 CA 2138625A1
- Authority
- CA
- Canada
- Prior art keywords
- synchronization mechanism
- thread
- acquire
- time
- resource
- 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.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
Abstract
A method and system for managing ownership of a released synchronization mechanism is provided. In a preferred embodiment, a number of entities, such as threads, are attempting to acquire the synchronization mechanism when the synchronization mechanism becomes available. Each of the entities has a priority indicator that indicates the relative urgency of the attempt by the entity to acquire the synchronization mechanism. The method and system first identifies one of the entities attempting to acquire the synchronization mechanism that has the priority indicator that indicates that its attempt to acquire the synchronization mechanism is of the highest urgency. The method and system then determines whether any entity attempted to acquire the synchronization mechanism during a foregoing selected period of time. If an entity has attempted to acquire the synchronization mechanism during the selected period of time, then the method and system assigns ownership of the synchronization mechanism to the identified entity. If no entity has attempted to acquire the synchronization mechanism during the selected period of time, then the method and system defers the assignment of ownership of the synchronization mechanism to a later time.
Description
Description METHOD AND SYSTEM FOR MANAGING OWNERSHIP OF A RELEASED
SYNCHRONIZATION MECHANISM
Technical Field The invention relates generally to a method and system for synchroni~ing resource use in a co~ ul~ ~ system, and, mcre specifically, to a method and system for m~n~ging ownership of a released synchlo~ dlion mech~niem fvr 10 synchronizing resource use.
Background of the Invention Many modern con~ulel operating systems are able to execute several programs ~imlllt~neously. Such opel~Lillg systems are termed mllltit~e~insg operating 15 systems. In a multit~cking ope.aLi~g system, each executing program is assigned a thread. A thread is a unit of execution. Each thread is associated with a threadexecution block data structure for storing the information required to manage the execution of a portion of a single program, such as a program counter for tracl~ing the instruction of the program ~;uLlellLly being executed. Each thread typically contains a 20 priority value indicating the relative urgency of its execution. While at least one thread must be assigned to each executing program, a single program may have more than one thread ~esi~nP(l to it if a user desires to execute different parts of that program eiml]lt~nPously. An op~ ldlUlg system in which more than one thread may be ~c~i~nPd to a single program is called a multi-threaded op. ~dLUlg system. In a mllltit~el~ing 25 Op~d~ulg system running on a co~ ul~r system having multiple central procP,ssing units (CPUs), di~elll threads may actu~lly execute simultaneously on di~t processors. On the other hand, in a mlllti~sl~in~ opeldLiug system running on a single CPU, only one thread may be actually e~ecuLillg at any given time. In this case, the multitaslcing operating system gives the impression of simultaneous execution allowing 30 the threads to each execute for a short periods of time. A period in which the mlllti~el~ing operating system allows a particular thread to execute is called that thread's time slice. Time slices are scheduled via the mulLi~ operating system by considering both the relative priority of each of the threads and the recency of each thread's last time slice. That is, higher priority threads are scheduled before lower 35 priority threads. Further, threads that have not recently received a tirne slice are scheduled before threads that have recently received a time slice.
213862~
In a m~ k;~.g Op~ ldlillg system (h~ ,. simply 'lope.dlillg system"), it is sometimes nPcecczlry to coorli~dt~ the ~cl~tion of multiple threads sePking to use the same resource. For example, it is i~ L~l to ensure that a hard disk drive is never used by more than one thread at the same time, as a thread using the hard 5 disk drive is likely to depend on the state of the hard disk drive, which can be changed by another t~hread using the hard disk drive. Operating systems, therefore, usually provide one or more synchronization meçhzlni~m~ to coordinate the execution of multiple threads seeking to use the same resource. Syllchrol~iGd~ion meçhstni~m~generally restrict the use of use of a particular resource to a predetermined l~ Xillllllll 10 number of threads (often one). A synchroni~dlion me~hzmi~m is in this way said to " the resources whose use it restricts. Examples of syncl~l~onizdLion me~hzmi~m~ include sPmztrhores, which are typically used to control the use of a shared resource that can support a limited nurnber of multiple users; mutual exclusion mechzlni~m~ (mlltPYçs), which are typically used to control the use of a shared resource 15 that can only support a single user; and critical code sections (critical sections), which are usually used to limit access to a series of pro~,...~ ;t~g instructions to one thread at a time. An op~ .d~ g system might use a mutex to ensure that a hard disk drive is never used by more th~n one thread at the same time.
A thread that needs to use a resource that is protected by a 20 synchronization meçhzlnicm first a~Le~ t, to acquire the synchronization me~hzmi~m In order to attempt to acquire the synchronization mechzlni~m, the program in which the thread is executing calls an operating system service for requesting ~yllchrol~ization me~ h~nicm~ The operating system service for requesting .,y..clllo~ d~ion mechzmi~m~
in turn calls an opcldLillg system service for acquiring ~yllcl~ ion mP~hzlnicm~25 Because a thread can call the op~.dL ng system service for requesting syllchLo~dlion . .~
merhzlni~m~ at any time at which it has the time slice, a thread's time slice also col,e~ollds to a period of time during which the thread may attempt to acquire asynch-o~ dlion mechzlni~m If fewer than the mS.x;~ .,,, number of threads are already using the resource, the ~yllcl~ dLion me~hzlni~m allows the thread dLL~ Li lg to30 acquire the syncll~o~ dLion meçhzlni~m to do so. To allow the thread alle~ lhlg to acquire the synchronization mechzlni~m to do so, the op~dLing system service foracquiring syncl~o~ dLion mech~ni~m~ returns a success return code to the ope.dLillg system service for requesting synchronization me~h~ni~m~, which returns a success return code to the program in which the thread is executing. When the return code is 35 the success return code, the program proçeeds to the steps in which it uses the resource that is protected by the synchronization meçh~ni~m If the maximum number of threads are already using the resource, the synchronization mech~nism does not allow the thread aLLe~ g to acquire it to do so. Rather, t_e synchrol~izdlion meçh~niem causes t_e thread ~ ling to acquire it to "block on" t_e synchronization mP~h~ni.em.
This involves the op~ ~alillg system facility for ac~ g synchlol~dlion mP~.h~nieme modifying the a-lmini.etrative i~lllldlion stored about the i~ .ntified thread to set a S blocked flag indicating that t_e thread is blocked. This also involves adding the identified thread to a list of threads that are blocked on the sy~cLoni~d~ion me~ h~niem A thread that has blocked on a ~yllc31ro~ lion meçh~niem cannot resume çx~cutinguntil it is unblocked by t_e synchl~ni~dlion m~r.h~niem. This is ac_ieved by theop~ ldling system by not p~ any "blocked" thread to receive a time slice. This 10 prevents the blocked thread from retllrning ~om the op~ ~dlil1g system to the application program and procee~iing to execute code that uses the- resource. When a syncLoni ~;~lion mech~niem unblocks a thread, it may or may not allow the unblocked thread to acquire the synclllol~lion me~h~niem If the ~yllcl~o~ization m~.h~ni.cm does allow the unblocked thread to acquire the synclllo~ dLion mech~niem by ~ lPing 15 a success return code from the service for acquiring syncl~rolfi~dlion mel.h~ni.em.e to the service for requesting syncl~.olfi~dlion me~h~ni.eme, the service for requestingsyncl~o~ dlion mç~h~niem.e returns a success code to the application program, and the thread may proceed to use the l~sou,ce plote~;led by the syncLol~i~dlion mPch~ni.em. If it does not by ~ g a failure return code to the service for requesting 20 synchlol~ization me~h~nieme the thread may not immediately use the lesollLce plole~ d by the synch~oni~lion mech~niem. In this case, the service for requesting synchr.)nizdlion mç~h~niem.e repeats its call to the service for acquiring synchronization merh~niem.e in a new attempt to acquire the synchlol~dlion me~.h~ni.em. Once thethread has acquired the ayllchlonization mech~niem and completed its use of the 25 protected resource, the thread releases the syncllrol~i~lion mech~niem so that other . .~
threads may acquire it and use the ~ Le~ d resource. The thread releases the synchronization mer.h~niem by calling an ope~d~ g system facility for rele~eing synchronizdlion me.~.h~ni.em.e. During the period of time immediately following the release of the synchronization mechanism, the syncl~o~ dlion meçh~niem is known as 30 "newly rele~eed "
A significant aspect of synchronization mer.h~ni.em design involves selecting a scheme for determining which of the threads that are blocked on a newly released synchronization meçh~ni.cm, if any, should be p~llllilled to acquire the synchronization mech~niem. This is known as m~n~ing ownership of the 35 synchro~ dlion mech~ni.em When fewer than two threads are blocked on the newly released synchrolli~dlion merh~niem, the scheme is trivial. When no threads are blocked on the newly released synchronization mech~niem, no threads need be 213862~
p~ ~milLed to acquire the syncl~o~ Lion mech~ni~m immediately, and the syncl,..)ni~Lion mPch~ni~m permits the first thread that subsequently ~lLem~l-, to acquire it to do so. When one thread is blocked on the newly released synchronization meçh~ni~m, the synch,oni~ ;nn mP~h~ni~m usually permits the sole blocked on thread 5 to acquire it. However, when two or more threads are blocked on the newly released synchronization mPch~ni~m, some scheme must be used to determine which blocked on thread should be pPrmittec~ to acquire it.
Di~.~llt srhemes have been used to cletP~rnine which of the threads that are blocked on a newly released synchronization meeh~ni~m~ if any, should be 10 permitte~l to acquire the synchronization mech~nicm Such schPrnPs are usuallyevaluated on the bases of the ~ lily of proces~in~ resources they COl~ C
("efflciency") and the fairness with which they distribute access to the resource prote~;led by the synchronization me~h~ni~m ("equity"). Equity is generally held to require adherence to two rules: (A) the syncl)l~o~ ion meçh~ni~m must always permit 15 itself to be acquired by the blocked thread having the highest priority and (B) if more than one blocked thread has the highest priority, the synchronization merh~nicm must permit itself to be acquired such that all of the blocked threads having the highest priority have equal O~Ol Lu~iLy to acquire the syncl~o~ ion mech~ni~m In a first sehpnlp~ the ~yllchlonization meeh~ni~m selects one blocked 20 thread to unblock, then immP~i~tely permits the sole unblocked thread to acquire the synch~olli~lion me~h~ni~m The synchronization meeh~ni~m typically selects the blocked thread having the highest priority, and selects a,l,iLl~uily from among multiple threads having the highest priority. The first scheme has the advantage that it is relatively equitable, ~flhPring closely to the two equity rules. The first scheme has the 25 disadvantage that it is relatively inefficient, because a thread is unable to release then reacquire the syncl~ol~Lion mP~h~ni~m in a single time slice. This causes a thread -~ switch for every acquisition of the synchronization meçh~ni~m by any thread. Because the contact switching associated with a thread switch consumes significant processing resources, the first scheme is relatively inefficient.
Figure 1 is a timing diagram demon,lld~ g the disadvantage of the first scheme for det~ i..g which of the threads that are blocked on a newly released synch.o~ lion me~h~ni~m should be pelllliLL~d to acquire the synchronization mech~nicm The timing diagram contains timelines 101, 102, 103, and 104, each corresponding to the activity of one of four threads having equal priorities. Each of the 35 timelines is compri~e~l of time slice periods, shown as ho,,7O,lLal rectangles, such as time slice 111 and wait periods, shown as horizontal line segTnents~ such as wait period 112. Each timeline also contains events, shown as labeled vertical line segments, such . ~
Z138~2~
as the attempt to acquire event and the assign event at time 113. The di~ L events shown are as follows: the attempt to acquire event ("At"), in which the thread all~
to acquire the syncl~o~ lion me~hRnicm; the assigned event ("As"), in which the synchn).~ n m~hRnicm is RcsignPd to the thread; the release event ("R"), in which 5 the owning thread releases the synchroni7Rtion m~l hRnicm; and the unblocking event ("UB"), in which a thread blocked on the ~yllchlol~izalion m~?~hRnicm is unblocked.
Finally, each timeline also reflects states bclw~ell events. These are shown as labels between events. As an example, the owned state during interval 114 of the synchloni~lion m~hRnicm by the first thread exists for the period of tirne between the 10 attempt to acquire event and the RCcignment event at time 113 and the release event at time llS. Each thread, and therefore each timeline, has three di~l states: an owned state ("O"), in which the thread owns the synch,unizalion me~hRnicm, such as the owned state during interval 114; an unowned, unblocked state (no label), in which the thread does not own the synchlo~ ion me~hRnicm and is not blocked, such as the 15 unowned unblocked state 116; and a blocked state ("B"), in which the thread is blocked on the ~yllcl~lo~ lion mechRnicm, such as the blocked state during interval 117. For the convenience of the reader, the major events depicted in Figure 1 are listed below in chronological order in Table 1.
time thread event 113 1 alle.l,~ to acquire; p~ll~ d to acquire 118 2 all~ ~ to acquire; blocks 119 3 all~ to acquire; blocks 120 4 ~lle~ to acquire; blocks llS ~ 1 releases 121 2 permitted to acquire 122 1 allelll~l~ to reacquire; blocks 123 2 releases 129 2 alltlll~)~ to reacquire; blocks 125 3 releases 130 3 alle~ ls to reacquire; blocks 126 4 releases 131 4 aLl~ to reacquire; blocks 127 1 releases 132 1 ~Llempl~ to reàcquire, blocks Table 1 21386~5 -. 6 Initially the first thread receives a time slice 111 of processor time.
During the time slice, the first thread s~ccessf~ y alLt~ ,L~ to acquire the sync~o~ ion me~h~ni.~m by calling the service for requesting synchlo~ ;on S mech~ni.cm~, which in turn calls the service for acquiring s~,ncl~ol~ l;on m.och~ni.cm.~
Note the attempt to acquire event and the assign event at time 113. The first thread owns the synchronization me~h~ni~m thereafter during the owned state during interval 114. At time 118, the second thread has the time slice and similarly alL~lllpL~ to acquire the synchronization mech~ni~m. The attempt by the second thread fails because the 10 synchronization mer.h~ni.cm is not available, i.e., is owned by the first thread. The second thread therefore blocks. At times 119 and 120, the third and fourth threads also attempt to acquire the syllch~oni~Lion meçh~ni~m when they receive the time slice.
Since the syncl~rol~izaLion m~rh~ni~m is not available, the third and fourth threads block. Because the second, third, and fourth threads are blocked, the f~rst thread 15 l~,ct:ives the next time slice. At time 115, the first thread releases the syncllloniz~Lion me~h~ni~m. The circle around the "R" label shows that under the first srhemç~ the release causes the synchrol~i~Lion mech~ni~m to be rç~c.ci~ned imme(1i~t~ly. This is indicated by the assign event and the unblock event at time 121. At this point, the second thread begins owning the synchronization meçh~ni~m, pUL~ to its attempt to 20 acquire it at -tirne 118. While the second thread has been unblocked, it cannot use the synchronization mech~ni.cm until it receives the time slice. The second thread receives the time slice at time 122, when the first thread aLLelll~L~ to reacquire the synchronization mech~ni~m. Because the ~yllclllollization mech~ni.~m is not available, the attempt fails, and the first thread blocks, as can be seen by the blocked state at time 25 117. A second thread uses the synchronization me~h~ni~m during the first part of its ....
time slice then releases the ~y.lcl~oni;~Lion me~.h~ni~m at time 123. The third thread is assigned ownership of the ~yllcl~ol~Lion me~h~ni~m at time 124 and unblocked as the result of the release event at time 123. The cycle continues with release of the synchrol~i;~Lion me.~h~ni.~m by the respective threads at times 125, 126, 127, and 128, 30 causing re~ nment of the synchronization me~h~ni.~m and subsequent ~Ue~ to reacquire the syncLoni~Lion mech~ni~m by the same thread, shown by attempt events at times 129, 130, 131, and 132, which, in tum, causes a thread switch before the synchronization mech~ni~m can be acquired again.
In a second scheme, the synchronization mech~ni.~m unblocks the 35 blocked thread having the highest priority, but does not immediately permit any thread to acquire the synchlo~ Lion mech~ni~m. When the unblocked thread receives its ne~t time slice, the unblocked thread repeats its attempt to acquire the synch~olli~Lion mPrh~ni~m. If the synchrol~dlion ~ h~ m is available, the ~y~ ol~i~dlion merh~ni~m permits the unblocked thread to acquire the ~;yllcLo~dlion ...~ç~ m Further, if two or more threads have the highest priority, the priority ranking of threads by the opeldLillg system adds a degree of randomness to selection ~ the threads 5 having the highest priority. The second scheme has the disadvantage, however, that it permits a single thread to monopolize the sy-nchlonizd~ion mçrh~ni.~m Figure 2 is a timing diagram demonstrating the disadvantage of the second scheme for d~t.. i~ -g which of the threads that are blocked on the newly released syncl~ol~i~dtion mech~ni~m should be p~rmitted to acquire the synchronization 10 merh~ni~m The timing diagram contains timelines 201, 202, 203, and 204. The timelines correspond to the activity of a first, second, third, and fourth thread, le~e~;lively, each of which has the same priority. For the collv~nience of the reader, the major events depicted in Figure 2 are listed below in chronological order in Table 2.
time thread ~n~
205 1 alL~ L~ to acquire; p~ lefl to acquire 207 2 aLL~ to acquire; blocks 208 3 dLlellll.L~ to acquire; blocks 209 4 ~lLelll~t~ to acquire; blocks 216 1 releases 217 1 ~ Ls to reacquire; permitte~l to reacquire 218 1 releases 213 1 ~ L~ to l~ac~ ; p~ ".;ll~(l to reacquire 215 2 ~Lle~ JLS to acquire; blocks 219 ,. 1 releases 220 1 ~ L~ to reacquire; p~ ;Lle(i to reacquire 221 1 releases 222 1 ~LLe~ to reacquire; pL. ".il le~ to reacquire 223 2 ~ to acquire; blocks 224 1 releases - Table 2 The first thread receives the first time slice. At time 205, the first thread s~1çcPssfillly aLlel"~l~ to acquire the ~yllchlulli~a~ion merh~ni~m. The first thread owns 20 the synchrol~-~Lion meçh~ni~m during time interval 206. After the first thread time slice e~cpires, the second, third, and fourth threads each receive a time slice and attempt - 2138~25: -to acquire the synchronization mP~h~ni~m and attempt to acquire events at times 207, 208, and 209, respectively. Since the synchronization ~ rh~niim is owned by the first thread and unavailable, each of these three attempts to acquire the synchronization mech~ni~m fail, causing the second, third and fourth threads to be blocked, as shown by S the blocked states during time intervals 210, 211, and 212, respectively. After the second, third, and fourth threads block, the first thread receives the next ti_e slice. The first thread releases and successfully ~lle~ to reacquire the ~yllchl~JI~iz~lionm~çh~ni~m several times. Note the release events at tirnes 216 and 218, and the attempt to acquire events at times 217 and 213. The rectangle around the "R" label of the release events in Figure 2 shows that under the second scheme, a blocked on thread is unblocked on release but is not permitted to acquire the synchronization meçh~ni~m Before this time slice expires, the first thread sl1cce~ 11y attempts to acquire the synchroni7~tion m~h~ni~m at time 213. When the second thread receives a time slice at the expiration of the first thread time slice, the first thread still owns the synchronization me~h~ni~m, as shown by the owned state during interval 214.
Therefore, when the second thread alLe"~l~ to acquire the synchroni_ation mech~*i.~m at time 215, the attempt fails. The second thread is blocked and, since the second, third and four~ threads are again all blocked, the first thread receives the next time slice.
The first thread again releases and successfully alLe~ to reacquire the synchronization mech~ni~m during its time slice, owning it when its time slice expires.
Note the release events at times 219 and 221, and the attempt to acquire events at times 220 and 222. The cycle continues when the second thread always failing in its attempts to acquire the synchl.)l~iz~lion mech~ni~m and the third and fourth threads never having another chance to attempt to acquire the syncl~o~ lion merh~ni~m The overall effect is the total monopolization of the synchlolli~Lion me~h~ni~m by the first thread.
As can be seen from the above discussion, existing schemes for tr~n~fPrring the ownership of a released synchrol~i~Lion mech~ni~m are either inefficient or inequitable.
Summary of the Invention It is an object of the invention to provide a method and system in a coll~u~ system for m~n~in~ ownership of a synchronization mech~ni~m It is another object of the invention to provide a method and system in a colll~ulei system for ~si~ning the ownership of a synchroni7~tion mech~nism It is a yet another object ofthe invention to provide a method and system in a computer system for del~.",i~ g whether to reassign ownership of a 21~8625 .
g synchronization merh~ni~m formerly acquired and released by a formerly owning thread.
It is a further object of the invention to provide a method and system in a computer system for d~te.,lli~ whether to permit use of a resource by a selected S requesting thread that is requesting to use the resource before the requesting thread next requests to use the resource.
These and other objects, which will become app~elll as the invention is more fully described below, are provided by a method and system for m~n~ging ownership of a ~yllch~oni~Lion mPch~ni~m In a pl~r~lled embodiment, a number of 10 entities, such as threads, are ~leml~Lillg to acquire the synchronization mPrh~ni~m when the synchronization mech~ni~m becomes available. Each of the entities has a priorit,v indicator that in~1ir,~t~Ps the relative ulgen~;y of the attempt by the entity to acquire the syncl~o~i~lion merh~ni~m The method and system first identifies one of the entities ~Ue~ Li~g to acquire the syncl~oni~lion merh~ni~m that has the priority indicator that 15 in-lir,~tP~ that its attempt to acquire the syncl~ol~iGILion mech~ni~m is of the highest u~gel~;y. The method and system then detelminPs whether any entity all~ ted to acquire the synch~ol~i~Lion mel h~ni~m during a foregoing selected period of time. If an entity has attempted to acquire the synchronization meçh~ni~m during the selected - period of time, then the method and system assigns ow~ hip of the synchronization me~h~ni~m to the identified entity. If no entity has ~ l~led to acquire the syncllloni~Lion mech~ni~m during the selected period of time, then the method and system defers the ~signment of ownership of the syncl~Jniz~lion meçh~nicm to a later time.
Brief Descri~?tion of the Drawir~
Figure 1 is a timing diagram demol~ Lii~g the disadvantage of a first conventional scheme for d~L` Illinill~ which of the threads that are blocked on a newly released synchronization me~h~ni~m should be permitt~d to acquire the syncLo~Lion mech~ni~m Figure 2 is a timing diagram demonstrating the disadvantage of a second conventional scheme for d~lr.ll~ g which of the threads that are blocked on the newly released synchronization me~ h~ni~m should be permitted to acquire the syncl., oni~Lion mech~ni~m Figure 3 is a high-level block diagram of an illustrative general-purpose computer system upon which the facilit;y that constitutes the preferred embodiment operates.
`- 2J38625 Figure 4 is a flow diagram showing the steps carried out by the facility 304 when the synchlul~i~lion mer.h~ni.cm is released.
Figure S is a timing diagram illustrating the operation of the facility- 304.
5 net~iled T)escription of the Invenhon The plcf~ d embodiment of the present invention provides an efficient and equitable method and system for transferring ownership of a releaced sync~ol~izalion m~rh~nicm In the pl~f~ d embc~iim~nt~ when a thread releases a .. ~yllchroi~lion m~rh~ni~m, if any threads are blocked on the releace ~yllchtoni;c~lion mech~niem, a software facility for m~n~ging ownership of the synchronization mech~ni.cm (the facility) unblockc the blocked on thread having the highest priority.
The facility further cl~lr~ es whether any thread has blocked on the syncllronizalion mech~ni.cm since the synchronization mech~ni~m was last acquired. If so, then either a thread with a higher priority than the releasing thread has aL~el~ ed to acquire the ~yllcl~onization mech~ni.~m, or the operating system has given a time slice to a thread having the same priority as the releasing thread. In these cases, the facility immefli~t~y permits the unblocked thread to acquire the synchronization merh~ni~m This allows the thread with a higher priority than the releasing thread that has ~U~ L~d to acquire the synchronization m,oçh~ni~m or the thread having the same priority as the releasing thread that has received a time slice to immediately æquire the synchronization mech~ni~m Otherwise, the facility does not permit any thread to imme~ tely acquire the synchronization mech~ni~m This allows the releasing thread to reacquire the syncl~lol~i~lion meçh~ni.~m while its tirne slice continll~s, and allows the next thread that receives a time slice and ~Ll~ L~ to æquire the ~yllcllroni~lion m~ch~ni~m to do so.
....
Figure 3 is a high-level block diagram of an illustrative general-purpose Co~ ;l system within which the facility op~ l~les. The colllyu~r system 300 contains a central proces.cin~ unit (CPU) 301, a conl~uh~ memory (memory) 302, and input/output devices 303. The facility 304 is stored in the memory 302 and executes on the CPU 301. Other programs 3q6, 307, and 308 are also stored in the memory 302, as are ~lmini~trative task information blocks 309, 310, and 311 which each holds a~mini~trative task information about the task executing in one of the programs 306, 307, and 308. The ope~dLing system 312 is also stored in the memory 302. Among the input/output devices is a storage device 305, such as a hard disk drive.
A thread that needs to use a resource that is protected by a synchronization mech~ni.~m first a~ to acquire the synchronization merh~ni.sm Itshould be appreciated that synchronization meçh~ni.cm~ include at least semaphores, 2138~25 mutual exclusion mech~ni~m~ (mutexes), and critical code sections (critical sections).
Synchlo~ dLion mech~ni.~m.c may protect such resources as storage devices, net~vork adapters, serial co~ ications adapters, display devices, sel~iLiv~ sections of code, sensitive regions of memory, and other resources that may only be used by a limited 5 number of threads at a time. The limited number of threads that may use a resource protected by synchronization mechanism at a single time is called the ,,.i.x;,.......
number of threads for the synchronization me~h~ni~m, and is a characteristic of the particular synchronization mer.h~ni~m that protects the plotecled resource.
In order to attempt to acquire the synchlol~i~Lion mech~ni~m, the 10 program in which the thread is e~ecutin2 calls an operating system service for requesting synchronization mP~.h~ni.cm.c which in turn calls an ope~dLillg system service for acquiring synchronization mec.h~ni~m~ If fewer than the mS1x;.,,l~,,, number of threads are already using the resource, the syncl~rol~i2dLion mech~ni~m allows the thread dUelllyLing to acquire the synchronization me.~h~ni.cm to do so. To allow the 15 thread dll~pting to acquire the synchn)~ dlion mech~ni.~m to do so, the operating system service for acquiring synchronization me~h~ni.cm~ a success return code to the o~ldling system service for requesting synchrol~ zdlion mech~ni~m.c, which returns a success return call to the program in which the thread is executing. When the return code is the success return code, the program proceeds to the steps where it uses 20 the resource that is protected by the synch~ollizd~ion mech~ni~m. If the m;.x;",l~", number of threads are already using the resource, the synch~o~i;cdlion me~h~ni~m does not allow the thread all~lllylillg to acquire it to do so. Rather, the sy"chrolli~dlion mech~ni.~m causes the thread dlLenlyLillg to acquire it to "block on" the syncLollizdLion m~h~ni.cm. C~lcin~ the thread dLLelllyLi~g to acquire the synchronization me~h~nicm 25 to block on the synchronization mech~ni~m involves the operating system service for acquiring synchronization me~h~ni.cm.~ to modify the ~lmini.~ative information stored about the identified thread to set a blocked flag indicating that the thread is blocked.
Causing the thread aLl~l~Lillg to acquire the syncl~oni~dLion mech~ni.~m to block on the sync~on-~Lion me~h~ni.cm also involves adding the identified thread to a list of 30 threads that are blocked on the syncl~Lv~ Lion mech~ni~m A thread that h~s blocked on a synclL~om~lion mechanism cannot resume executing until it is unblocked by the synchronization mech~ni.~m. This is achieved by the op~ ~dLillg system by not pcllllilLi lg any "blocked" thread to receive a time slice. This prevents the blocked thread from procee.ling to execute code in the program that uses the resource. When the return code 35 from the operating system service for a`c~ ing synchronization mech~ni~m~ is t_e failure return code, the program will not proceed to the steps where it uses t_e resource that is protected by the synchronization mech~ni~m. RaLher, the operating system 21~862~
service for requesting syncl~o~ dLion merh~nisme will call the Op~dLillg system service for acquiring synchronization m~rh~nisme again in another attempt to acquire the synchronization meçh~niem Figure 4 is a flow diagram showing the steps carried out by the facility 5 304 when the sync_ronization mech~niem is released. The steps shown in Figure 4 are only executed if one or more threads are blocked on the synchLoni~dlion mech~niem when it is released. If zero thrcads are blocked on the syncl~lo~d~ion mech~nismwhen it is released, a synchru~ ion mech~niem be_aves like a cûnventional syncl~ùl~izdLion merh~niem In step 401, the facility 304 identifies the blocked thread 10 having the highest priority. If, in step 401, there are no bIocked threads, then these steps termin~te (not shown). If, in step 401, more than one blocked t~ead has the highest pnority, then the facility 304 selects one of the threads ~l~iLIdl;ly. In step 402, the facility 304 unblocks the identified thread. This involves calling the opeldLillg system to modify the ~minietrative information stored about the identified thread to 15 clear the blocked flag. This step also includes removing the identified thread from the list of threads that are blocked on the synchl~ alion merh~niem In step 403, if a thread has blocked on the synchronization device since the last time the synchlolli;~Lion device was acquired, then the facility 304 continues at step 404, else these steps conclude without pc. ,..i~l;..g any thread to acquire the ~y.,cLoniz~lion merh~ni~m The 20 facility 304 makes the cletPrmin~tion in step 403 by cherking a freshly blocked unflag that is set each time a thread blocks on the synchrol-i7;~l ;on m~rh~ni.em and cleared each time the syncl~olli;~Lion me~h~niem is released. In step 404, the facility 304 permits the iclentified thread to acquire the syllchrol~ization ll,ech~..;em Step 404 involves storing the thread as the owner of the syncl~o~ 1ion mech~niem This step also includes l~L~ g success to the opcl~Lillg system service for requesting ~yllchron~Lion me~h~nieme on return from the opclaLillg system service for acquiring synchloni~lion m~ch~nieme The Op~,ldlillg system se~vice for requesting ~yllcLol~i~LiOn m~h~nieme then returns success to the op~,ldLi~g system service for acquiring syncl~n-~Lion m~rh~nieme These steps then conclude.
Figure S is a timing diagram demon~Ll~Lil~g the advantages of the facility 304. The timing diagram contains timelines 501, 502, 503, and 504, which COrl~ s~ol-d to the activity of a first, secon~d, third, and fourth thread, lc~ye~;Li~ely. The four threads all have the same priority. For the convenience of the reader, the major events depicted in Figure S are listed below in chronological order in Table 3.
;
213~525 -time thread event 505 1 ~L~ L~ to acquire; p~ iLI~ to acquire 506 2 allel~ to acquire;blocks 512 3 ~LL~m~ to acquire; blocks 513 4 aLLc.ll~L~ to acquire; blocks 507 1 releases 508 2 unblocked; assigns ownership 509 2 releases 510 3 unblocked 511 1 aLL~ L~ to reacquire; p~ llecl to reacquire Table 3 The first thread lcc~ives the first time slice and s~lcces~fillly ~llclll~l~ to 5 acquire the synchronization mech~ni~m at tirne 505. Thereafter, the synchronization meçh~ni~m is owned by the first thread. The second thread gets the next time slice, during which it unsuccessfully ~LLem~L~ to acquire the synchronization me~h~ni~m at time 506. The second thread is th~.~dlL~. blocked as shown by the asterisk following the "At" label of the attempt to acquire event at time 506, the attempt to acquire causes 10 the facility to set the freshly blocked on flag. The third and fourth threads subsequently receive time slices and unsuccescfillly attempt to acquire the synchroni7~1;0n meçh~ni~m at times 512 and 513 respectively, and therefore block thereafter. Because the second, third and fourth threads are blocked, the first thread receives the next time slice. At time 507, the first thread releases the ~yllchl~l~i~Lion m. rh~ni~m The 15 facility checks whether the freshly blocked nnflag is set in step 403. It is, because no thread has acquiréd the synchronization me~h~ni~m since time 506 when the secondthread ~lLe~ led to acquire the synchloniz~lion mP~h~ni~m The circle around the "R"
label of the release event at time 507 shows that on release, the facility unblocks the second thread and assigns the sy-n,h,oni~lLion mech~ni~m to the second thread at time 20 508. The second thread thereafter owns the synchronization mech~ni~m, and may use it as soon as it receives the next time slice. In the foLcgoing, the first thread was plcvc~lled from monopolizing the sync~ollizaLion mech~ni~m for more than two of its conse~;ulive time slices.
During its time slice, the second thread releases the synchronization 25 mech~nicm at time 509. As shown by the rectangle around the "R" label of the release event at time 509, the freshly blocked unflag is not set and ~erefore the third thread is unblocked at time 510, but ~e s,~chronization mech~ni~m is not reassigned. This . .
permits the second thread to succeed at its attempt to lt~C~luiLe, the ~yllc~oni~Lion mer.h~ni.~m at time 511, later during the same time slice. In folegoillg, subsequent ~LLe111~ by the same thread to acquire the ~yucLo~ ;on mech~ni~m during the sametime slice do not cause an ~A~,~ive thread switch unless other threads have alL~ ed 5 to acquire the ~yllchro.~ ;on m~ch~ni~m during owning thread's ow.... ~1.ip While this invention has been shown and described with ~fe.e.lcc to prert;llcd embodiments, it will be mrlerstood by those skilled in the art that various changes or modifications in forrn and detail may be made without depar~g from the scope of the invention. For example, it could be used for any use regulation device in -, 10 which resource users are so. I~el ;l l.~s required to wait before they are p. . ", il~ecl to use a resource.
SYNCHRONIZATION MECHANISM
Technical Field The invention relates generally to a method and system for synchroni~ing resource use in a co~ ul~ ~ system, and, mcre specifically, to a method and system for m~n~ging ownership of a released synchlo~ dlion mech~niem fvr 10 synchronizing resource use.
Background of the Invention Many modern con~ulel operating systems are able to execute several programs ~imlllt~neously. Such opel~Lillg systems are termed mllltit~e~insg operating 15 systems. In a multit~cking ope.aLi~g system, each executing program is assigned a thread. A thread is a unit of execution. Each thread is associated with a threadexecution block data structure for storing the information required to manage the execution of a portion of a single program, such as a program counter for tracl~ing the instruction of the program ~;uLlellLly being executed. Each thread typically contains a 20 priority value indicating the relative urgency of its execution. While at least one thread must be assigned to each executing program, a single program may have more than one thread ~esi~nP(l to it if a user desires to execute different parts of that program eiml]lt~nPously. An op~ ldlUlg system in which more than one thread may be ~c~i~nPd to a single program is called a multi-threaded op. ~dLUlg system. In a mllltit~el~ing 25 Op~d~ulg system running on a co~ ul~r system having multiple central procP,ssing units (CPUs), di~elll threads may actu~lly execute simultaneously on di~t processors. On the other hand, in a mlllti~sl~in~ opeldLiug system running on a single CPU, only one thread may be actually e~ecuLillg at any given time. In this case, the multitaslcing operating system gives the impression of simultaneous execution allowing 30 the threads to each execute for a short periods of time. A period in which the mlllti~el~ing operating system allows a particular thread to execute is called that thread's time slice. Time slices are scheduled via the mulLi~ operating system by considering both the relative priority of each of the threads and the recency of each thread's last time slice. That is, higher priority threads are scheduled before lower 35 priority threads. Further, threads that have not recently received a tirne slice are scheduled before threads that have recently received a time slice.
213862~
In a m~ k;~.g Op~ ldlillg system (h~ ,. simply 'lope.dlillg system"), it is sometimes nPcecczlry to coorli~dt~ the ~cl~tion of multiple threads sePking to use the same resource. For example, it is i~ L~l to ensure that a hard disk drive is never used by more than one thread at the same time, as a thread using the hard 5 disk drive is likely to depend on the state of the hard disk drive, which can be changed by another t~hread using the hard disk drive. Operating systems, therefore, usually provide one or more synchronization meçhzlni~m~ to coordinate the execution of multiple threads seeking to use the same resource. Syllchrol~iGd~ion meçhstni~m~generally restrict the use of use of a particular resource to a predetermined l~ Xillllllll 10 number of threads (often one). A synchroni~dlion me~hzmi~m is in this way said to " the resources whose use it restricts. Examples of syncl~l~onizdLion me~hzmi~m~ include sPmztrhores, which are typically used to control the use of a shared resource that can support a limited nurnber of multiple users; mutual exclusion mechzlni~m~ (mlltPYçs), which are typically used to control the use of a shared resource 15 that can only support a single user; and critical code sections (critical sections), which are usually used to limit access to a series of pro~,...~ ;t~g instructions to one thread at a time. An op~ .d~ g system might use a mutex to ensure that a hard disk drive is never used by more th~n one thread at the same time.
A thread that needs to use a resource that is protected by a 20 synchronization meçhzlnicm first a~Le~ t, to acquire the synchronization me~hzmi~m In order to attempt to acquire the synchronization mechzlni~m, the program in which the thread is executing calls an operating system service for requesting ~yllchrol~ization me~ h~nicm~ The operating system service for requesting .,y..clllo~ d~ion mechzmi~m~
in turn calls an opcldLillg system service for acquiring ~yllcl~ ion mP~hzlnicm~25 Because a thread can call the op~.dL ng system service for requesting syllchLo~dlion . .~
merhzlni~m~ at any time at which it has the time slice, a thread's time slice also col,e~ollds to a period of time during which the thread may attempt to acquire asynch-o~ dlion mechzlni~m If fewer than the mS.x;~ .,,, number of threads are already using the resource, the ~yllcl~ dLion me~hzlni~m allows the thread dLL~ Li lg to30 acquire the syncll~o~ dLion meçhzlni~m to do so. To allow the thread alle~ lhlg to acquire the synchronization mechzlni~m to do so, the op~dLing system service foracquiring syncl~o~ dLion mech~ni~m~ returns a success return code to the ope.dLillg system service for requesting synchronization me~h~ni~m~, which returns a success return code to the program in which the thread is executing. When the return code is 35 the success return code, the program proçeeds to the steps in which it uses the resource that is protected by the synchronization meçh~ni~m If the maximum number of threads are already using the resource, the synchronization mech~nism does not allow the thread aLLe~ g to acquire it to do so. Rather, t_e synchrol~izdlion meçh~niem causes t_e thread ~ ling to acquire it to "block on" t_e synchronization mP~h~ni.em.
This involves the op~ ~alillg system facility for ac~ g synchlol~dlion mP~.h~nieme modifying the a-lmini.etrative i~lllldlion stored about the i~ .ntified thread to set a S blocked flag indicating that t_e thread is blocked. This also involves adding the identified thread to a list of threads that are blocked on the sy~cLoni~d~ion me~ h~niem A thread that has blocked on a ~yllc31ro~ lion meçh~niem cannot resume çx~cutinguntil it is unblocked by t_e synchl~ni~dlion m~r.h~niem. This is ac_ieved by theop~ ldling system by not p~ any "blocked" thread to receive a time slice. This 10 prevents the blocked thread from retllrning ~om the op~ ~dlil1g system to the application program and procee~iing to execute code that uses the- resource. When a syncLoni ~;~lion mech~niem unblocks a thread, it may or may not allow the unblocked thread to acquire the synclllol~lion me~h~niem If the ~yllcl~o~ization m~.h~ni.cm does allow the unblocked thread to acquire the synclllo~ dLion mech~niem by ~ lPing 15 a success return code from the service for acquiring syncl~rolfi~dlion mel.h~ni.em.e to the service for requesting syncl~.olfi~dlion me~h~ni.eme, the service for requestingsyncl~o~ dlion mç~h~niem.e returns a success code to the application program, and the thread may proceed to use the l~sou,ce plote~;led by the syncLol~i~dlion mPch~ni.em. If it does not by ~ g a failure return code to the service for requesting 20 synchlol~ization me~h~nieme the thread may not immediately use the lesollLce plole~ d by the synch~oni~lion mech~niem. In this case, the service for requesting synchr.)nizdlion mç~h~niem.e repeats its call to the service for acquiring synchronization merh~niem.e in a new attempt to acquire the synchlol~dlion me~.h~ni.em. Once thethread has acquired the ayllchlonization mech~niem and completed its use of the 25 protected resource, the thread releases the syncllrol~i~lion mech~niem so that other . .~
threads may acquire it and use the ~ Le~ d resource. The thread releases the synchronization mer.h~niem by calling an ope~d~ g system facility for rele~eing synchronizdlion me.~.h~ni.em.e. During the period of time immediately following the release of the synchronization mechanism, the syncl~o~ dlion meçh~niem is known as 30 "newly rele~eed "
A significant aspect of synchronization mer.h~ni.em design involves selecting a scheme for determining which of the threads that are blocked on a newly released synchronization meçh~ni.cm, if any, should be p~llllilled to acquire the synchronization mech~niem. This is known as m~n~ing ownership of the 35 synchro~ dlion mech~ni.em When fewer than two threads are blocked on the newly released synchrolli~dlion merh~niem, the scheme is trivial. When no threads are blocked on the newly released synchronization mech~niem, no threads need be 213862~
p~ ~milLed to acquire the syncl~o~ Lion mech~ni~m immediately, and the syncl,..)ni~Lion mPch~ni~m permits the first thread that subsequently ~lLem~l-, to acquire it to do so. When one thread is blocked on the newly released synchronization meçh~ni~m, the synch,oni~ ;nn mP~h~ni~m usually permits the sole blocked on thread 5 to acquire it. However, when two or more threads are blocked on the newly released synchronization mPch~ni~m, some scheme must be used to determine which blocked on thread should be pPrmittec~ to acquire it.
Di~.~llt srhemes have been used to cletP~rnine which of the threads that are blocked on a newly released synchronization meeh~ni~m~ if any, should be 10 permitte~l to acquire the synchronization mech~nicm Such schPrnPs are usuallyevaluated on the bases of the ~ lily of proces~in~ resources they COl~ C
("efflciency") and the fairness with which they distribute access to the resource prote~;led by the synchronization me~h~ni~m ("equity"). Equity is generally held to require adherence to two rules: (A) the syncl)l~o~ ion meçh~ni~m must always permit 15 itself to be acquired by the blocked thread having the highest priority and (B) if more than one blocked thread has the highest priority, the synchronization merh~nicm must permit itself to be acquired such that all of the blocked threads having the highest priority have equal O~Ol Lu~iLy to acquire the syncl~o~ ion mech~ni~m In a first sehpnlp~ the ~yllchlonization meeh~ni~m selects one blocked 20 thread to unblock, then immP~i~tely permits the sole unblocked thread to acquire the synch~olli~lion me~h~ni~m The synchronization meeh~ni~m typically selects the blocked thread having the highest priority, and selects a,l,iLl~uily from among multiple threads having the highest priority. The first scheme has the advantage that it is relatively equitable, ~flhPring closely to the two equity rules. The first scheme has the 25 disadvantage that it is relatively inefficient, because a thread is unable to release then reacquire the syncl~ol~Lion mP~h~ni~m in a single time slice. This causes a thread -~ switch for every acquisition of the synchronization meçh~ni~m by any thread. Because the contact switching associated with a thread switch consumes significant processing resources, the first scheme is relatively inefficient.
Figure 1 is a timing diagram demon,lld~ g the disadvantage of the first scheme for det~ i..g which of the threads that are blocked on a newly released synch.o~ lion me~h~ni~m should be pelllliLL~d to acquire the synchronization mech~nicm The timing diagram contains timelines 101, 102, 103, and 104, each corresponding to the activity of one of four threads having equal priorities. Each of the 35 timelines is compri~e~l of time slice periods, shown as ho,,7O,lLal rectangles, such as time slice 111 and wait periods, shown as horizontal line segTnents~ such as wait period 112. Each timeline also contains events, shown as labeled vertical line segments, such . ~
Z138~2~
as the attempt to acquire event and the assign event at time 113. The di~ L events shown are as follows: the attempt to acquire event ("At"), in which the thread all~
to acquire the syncl~o~ lion me~hRnicm; the assigned event ("As"), in which the synchn).~ n m~hRnicm is RcsignPd to the thread; the release event ("R"), in which 5 the owning thread releases the synchroni7Rtion m~l hRnicm; and the unblocking event ("UB"), in which a thread blocked on the ~yllchlol~izalion m~?~hRnicm is unblocked.
Finally, each timeline also reflects states bclw~ell events. These are shown as labels between events. As an example, the owned state during interval 114 of the synchloni~lion m~hRnicm by the first thread exists for the period of tirne between the 10 attempt to acquire event and the RCcignment event at time 113 and the release event at time llS. Each thread, and therefore each timeline, has three di~l states: an owned state ("O"), in which the thread owns the synch,unizalion me~hRnicm, such as the owned state during interval 114; an unowned, unblocked state (no label), in which the thread does not own the synchlo~ ion me~hRnicm and is not blocked, such as the 15 unowned unblocked state 116; and a blocked state ("B"), in which the thread is blocked on the ~yllcl~lo~ lion mechRnicm, such as the blocked state during interval 117. For the convenience of the reader, the major events depicted in Figure 1 are listed below in chronological order in Table 1.
time thread event 113 1 alle.l,~ to acquire; p~ll~ d to acquire 118 2 all~ ~ to acquire; blocks 119 3 all~ to acquire; blocks 120 4 ~lle~ to acquire; blocks llS ~ 1 releases 121 2 permitted to acquire 122 1 allelll~l~ to reacquire; blocks 123 2 releases 129 2 alltlll~)~ to reacquire; blocks 125 3 releases 130 3 alle~ ls to reacquire; blocks 126 4 releases 131 4 aLl~ to reacquire; blocks 127 1 releases 132 1 ~Llempl~ to reàcquire, blocks Table 1 21386~5 -. 6 Initially the first thread receives a time slice 111 of processor time.
During the time slice, the first thread s~ccessf~ y alLt~ ,L~ to acquire the sync~o~ ion me~h~ni.~m by calling the service for requesting synchlo~ ;on S mech~ni.cm~, which in turn calls the service for acquiring s~,ncl~ol~ l;on m.och~ni.cm.~
Note the attempt to acquire event and the assign event at time 113. The first thread owns the synchronization me~h~ni~m thereafter during the owned state during interval 114. At time 118, the second thread has the time slice and similarly alL~lllpL~ to acquire the synchronization mech~ni~m. The attempt by the second thread fails because the 10 synchronization mer.h~ni.cm is not available, i.e., is owned by the first thread. The second thread therefore blocks. At times 119 and 120, the third and fourth threads also attempt to acquire the syllch~oni~Lion meçh~ni~m when they receive the time slice.
Since the syncl~rol~izaLion m~rh~ni~m is not available, the third and fourth threads block. Because the second, third, and fourth threads are blocked, the f~rst thread 15 l~,ct:ives the next time slice. At time 115, the first thread releases the syncllloniz~Lion me~h~ni~m. The circle around the "R" label shows that under the first srhemç~ the release causes the synchrol~i~Lion mech~ni~m to be rç~c.ci~ned imme(1i~t~ly. This is indicated by the assign event and the unblock event at time 121. At this point, the second thread begins owning the synchronization meçh~ni~m, pUL~ to its attempt to 20 acquire it at -tirne 118. While the second thread has been unblocked, it cannot use the synchronization mech~ni.cm until it receives the time slice. The second thread receives the time slice at time 122, when the first thread aLLelll~L~ to reacquire the synchronization mech~ni~m. Because the ~yllclllollization mech~ni.~m is not available, the attempt fails, and the first thread blocks, as can be seen by the blocked state at time 25 117. A second thread uses the synchronization me~h~ni~m during the first part of its ....
time slice then releases the ~y.lcl~oni;~Lion me~.h~ni~m at time 123. The third thread is assigned ownership of the ~yllcl~ol~Lion me~h~ni~m at time 124 and unblocked as the result of the release event at time 123. The cycle continues with release of the synchrol~i;~Lion me.~h~ni.~m by the respective threads at times 125, 126, 127, and 128, 30 causing re~ nment of the synchronization me~h~ni.~m and subsequent ~Ue~ to reacquire the syncLoni~Lion mech~ni~m by the same thread, shown by attempt events at times 129, 130, 131, and 132, which, in tum, causes a thread switch before the synchronization mech~ni~m can be acquired again.
In a second scheme, the synchronization mech~ni.~m unblocks the 35 blocked thread having the highest priority, but does not immediately permit any thread to acquire the synchlo~ Lion mech~ni~m. When the unblocked thread receives its ne~t time slice, the unblocked thread repeats its attempt to acquire the synch~olli~Lion mPrh~ni~m. If the synchrol~dlion ~ h~ m is available, the ~y~ ol~i~dlion merh~ni~m permits the unblocked thread to acquire the ~;yllcLo~dlion ...~ç~ m Further, if two or more threads have the highest priority, the priority ranking of threads by the opeldLillg system adds a degree of randomness to selection ~ the threads 5 having the highest priority. The second scheme has the disadvantage, however, that it permits a single thread to monopolize the sy-nchlonizd~ion mçrh~ni.~m Figure 2 is a timing diagram demonstrating the disadvantage of the second scheme for d~t.. i~ -g which of the threads that are blocked on the newly released syncl~ol~i~dtion mech~ni~m should be p~rmitted to acquire the synchronization 10 merh~ni~m The timing diagram contains timelines 201, 202, 203, and 204. The timelines correspond to the activity of a first, second, third, and fourth thread, le~e~;lively, each of which has the same priority. For the collv~nience of the reader, the major events depicted in Figure 2 are listed below in chronological order in Table 2.
time thread ~n~
205 1 alL~ L~ to acquire; p~ lefl to acquire 207 2 aLL~ to acquire; blocks 208 3 dLlellll.L~ to acquire; blocks 209 4 ~lLelll~t~ to acquire; blocks 216 1 releases 217 1 ~ Ls to reacquire; permitte~l to reacquire 218 1 releases 213 1 ~ L~ to l~ac~ ; p~ ".;ll~(l to reacquire 215 2 ~Lle~ JLS to acquire; blocks 219 ,. 1 releases 220 1 ~ L~ to reacquire; p~ ;Lle(i to reacquire 221 1 releases 222 1 ~LLe~ to reacquire; pL. ".il le~ to reacquire 223 2 ~ to acquire; blocks 224 1 releases - Table 2 The first thread receives the first time slice. At time 205, the first thread s~1çcPssfillly aLlel"~l~ to acquire the ~yllchlulli~a~ion merh~ni~m. The first thread owns 20 the synchrol~-~Lion meçh~ni~m during time interval 206. After the first thread time slice e~cpires, the second, third, and fourth threads each receive a time slice and attempt - 2138~25: -to acquire the synchronization mP~h~ni~m and attempt to acquire events at times 207, 208, and 209, respectively. Since the synchronization ~ rh~niim is owned by the first thread and unavailable, each of these three attempts to acquire the synchronization mech~ni~m fail, causing the second, third and fourth threads to be blocked, as shown by S the blocked states during time intervals 210, 211, and 212, respectively. After the second, third, and fourth threads block, the first thread receives the next ti_e slice. The first thread releases and successfully ~lle~ to reacquire the ~yllchl~JI~iz~lionm~çh~ni~m several times. Note the release events at tirnes 216 and 218, and the attempt to acquire events at times 217 and 213. The rectangle around the "R" label of the release events in Figure 2 shows that under the second scheme, a blocked on thread is unblocked on release but is not permitted to acquire the synchronization meçh~ni~m Before this time slice expires, the first thread sl1cce~ 11y attempts to acquire the synchroni7~tion m~h~ni~m at time 213. When the second thread receives a time slice at the expiration of the first thread time slice, the first thread still owns the synchronization me~h~ni~m, as shown by the owned state during interval 214.
Therefore, when the second thread alLe"~l~ to acquire the synchroni_ation mech~*i.~m at time 215, the attempt fails. The second thread is blocked and, since the second, third and four~ threads are again all blocked, the first thread receives the next time slice.
The first thread again releases and successfully alLe~ to reacquire the synchronization mech~ni~m during its time slice, owning it when its time slice expires.
Note the release events at times 219 and 221, and the attempt to acquire events at times 220 and 222. The cycle continues when the second thread always failing in its attempts to acquire the synchl.)l~iz~lion mech~ni~m and the third and fourth threads never having another chance to attempt to acquire the syncl~o~ lion merh~ni~m The overall effect is the total monopolization of the synchlolli~Lion me~h~ni~m by the first thread.
As can be seen from the above discussion, existing schemes for tr~n~fPrring the ownership of a released synchrol~i~Lion mech~ni~m are either inefficient or inequitable.
Summary of the Invention It is an object of the invention to provide a method and system in a coll~u~ system for m~n~in~ ownership of a synchronization mech~ni~m It is another object of the invention to provide a method and system in a colll~ulei system for ~si~ning the ownership of a synchroni7~tion mech~nism It is a yet another object ofthe invention to provide a method and system in a computer system for del~.",i~ g whether to reassign ownership of a 21~8625 .
g synchronization merh~ni~m formerly acquired and released by a formerly owning thread.
It is a further object of the invention to provide a method and system in a computer system for d~te.,lli~ whether to permit use of a resource by a selected S requesting thread that is requesting to use the resource before the requesting thread next requests to use the resource.
These and other objects, which will become app~elll as the invention is more fully described below, are provided by a method and system for m~n~ging ownership of a ~yllch~oni~Lion mPch~ni~m In a pl~r~lled embodiment, a number of 10 entities, such as threads, are ~leml~Lillg to acquire the synchronization mPrh~ni~m when the synchronization mech~ni~m becomes available. Each of the entities has a priorit,v indicator that in~1ir,~t~Ps the relative ulgen~;y of the attempt by the entity to acquire the syncl~o~i~lion merh~ni~m The method and system first identifies one of the entities ~Ue~ Li~g to acquire the syncl~oni~lion merh~ni~m that has the priority indicator that 15 in-lir,~tP~ that its attempt to acquire the syncl~ol~iGILion mech~ni~m is of the highest u~gel~;y. The method and system then detelminPs whether any entity all~ ted to acquire the synch~ol~i~Lion mel h~ni~m during a foregoing selected period of time. If an entity has attempted to acquire the synchronization meçh~ni~m during the selected - period of time, then the method and system assigns ow~ hip of the synchronization me~h~ni~m to the identified entity. If no entity has ~ l~led to acquire the syncllloni~Lion mech~ni~m during the selected period of time, then the method and system defers the ~signment of ownership of the syncl~Jniz~lion meçh~nicm to a later time.
Brief Descri~?tion of the Drawir~
Figure 1 is a timing diagram demol~ Lii~g the disadvantage of a first conventional scheme for d~L` Illinill~ which of the threads that are blocked on a newly released synchronization me~h~ni~m should be permitt~d to acquire the syncLo~Lion mech~ni~m Figure 2 is a timing diagram demonstrating the disadvantage of a second conventional scheme for d~lr.ll~ g which of the threads that are blocked on the newly released synchronization me~ h~ni~m should be permitted to acquire the syncl., oni~Lion mech~ni~m Figure 3 is a high-level block diagram of an illustrative general-purpose computer system upon which the facilit;y that constitutes the preferred embodiment operates.
`- 2J38625 Figure 4 is a flow diagram showing the steps carried out by the facility 304 when the synchlul~i~lion mer.h~ni.cm is released.
Figure S is a timing diagram illustrating the operation of the facility- 304.
5 net~iled T)escription of the Invenhon The plcf~ d embodiment of the present invention provides an efficient and equitable method and system for transferring ownership of a releaced sync~ol~izalion m~rh~nicm In the pl~f~ d embc~iim~nt~ when a thread releases a .. ~yllchroi~lion m~rh~ni~m, if any threads are blocked on the releace ~yllchtoni;c~lion mech~niem, a software facility for m~n~ging ownership of the synchronization mech~ni.cm (the facility) unblockc the blocked on thread having the highest priority.
The facility further cl~lr~ es whether any thread has blocked on the syncllronizalion mech~ni.cm since the synchronization mech~ni~m was last acquired. If so, then either a thread with a higher priority than the releasing thread has aL~el~ ed to acquire the ~yllcl~onization mech~ni.~m, or the operating system has given a time slice to a thread having the same priority as the releasing thread. In these cases, the facility immefli~t~y permits the unblocked thread to acquire the synchronization merh~ni~m This allows the thread with a higher priority than the releasing thread that has ~U~ L~d to acquire the synchronization m,oçh~ni~m or the thread having the same priority as the releasing thread that has received a time slice to immediately æquire the synchronization mech~ni~m Otherwise, the facility does not permit any thread to imme~ tely acquire the synchronization mech~ni~m This allows the releasing thread to reacquire the syncl~lol~i~lion meçh~ni.~m while its tirne slice continll~s, and allows the next thread that receives a time slice and ~Ll~ L~ to æquire the ~yllcllroni~lion m~ch~ni~m to do so.
....
Figure 3 is a high-level block diagram of an illustrative general-purpose Co~ ;l system within which the facility op~ l~les. The colllyu~r system 300 contains a central proces.cin~ unit (CPU) 301, a conl~uh~ memory (memory) 302, and input/output devices 303. The facility 304 is stored in the memory 302 and executes on the CPU 301. Other programs 3q6, 307, and 308 are also stored in the memory 302, as are ~lmini~trative task information blocks 309, 310, and 311 which each holds a~mini~trative task information about the task executing in one of the programs 306, 307, and 308. The ope~dLing system 312 is also stored in the memory 302. Among the input/output devices is a storage device 305, such as a hard disk drive.
A thread that needs to use a resource that is protected by a synchronization mech~ni.~m first a~ to acquire the synchronization merh~ni.sm Itshould be appreciated that synchronization meçh~ni.cm~ include at least semaphores, 2138~25 mutual exclusion mech~ni~m~ (mutexes), and critical code sections (critical sections).
Synchlo~ dLion mech~ni.~m.c may protect such resources as storage devices, net~vork adapters, serial co~ ications adapters, display devices, sel~iLiv~ sections of code, sensitive regions of memory, and other resources that may only be used by a limited 5 number of threads at a time. The limited number of threads that may use a resource protected by synchronization mechanism at a single time is called the ,,.i.x;,.......
number of threads for the synchronization me~h~ni~m, and is a characteristic of the particular synchronization mer.h~ni~m that protects the plotecled resource.
In order to attempt to acquire the synchlol~i~Lion mech~ni~m, the 10 program in which the thread is e~ecutin2 calls an operating system service for requesting synchronization mP~.h~ni.cm.c which in turn calls an ope~dLillg system service for acquiring synchronization mec.h~ni~m~ If fewer than the mS1x;.,,l~,,, number of threads are already using the resource, the syncl~rol~i2dLion mech~ni~m allows the thread dUelllyLing to acquire the synchronization me.~h~ni.cm to do so. To allow the 15 thread dll~pting to acquire the synchn)~ dlion mech~ni.~m to do so, the operating system service for acquiring synchronization me~h~ni.cm~ a success return code to the o~ldling system service for requesting synchrol~ zdlion mech~ni~m.c, which returns a success return call to the program in which the thread is executing. When the return code is the success return code, the program proceeds to the steps where it uses 20 the resource that is protected by the synch~ollizd~ion mech~ni~m. If the m;.x;",l~", number of threads are already using the resource, the synch~o~i;cdlion me~h~ni~m does not allow the thread all~lllylillg to acquire it to do so. Rather, the sy"chrolli~dlion mech~ni.~m causes the thread dlLenlyLillg to acquire it to "block on" the syncLollizdLion m~h~ni.cm. C~lcin~ the thread dLLelllyLi~g to acquire the synchronization me~h~nicm 25 to block on the synchronization mech~ni~m involves the operating system service for acquiring synchronization me~h~ni.cm.~ to modify the ~lmini.~ative information stored about the identified thread to set a blocked flag indicating that the thread is blocked.
Causing the thread aLl~l~Lillg to acquire the syncl~oni~dLion mech~ni.~m to block on the sync~on-~Lion me~h~ni.cm also involves adding the identified thread to a list of 30 threads that are blocked on the syncl~Lv~ Lion mech~ni~m A thread that h~s blocked on a synclL~om~lion mechanism cannot resume executing until it is unblocked by the synchronization mech~ni.~m. This is achieved by the op~ ~dLillg system by not pcllllilLi lg any "blocked" thread to receive a time slice. This prevents the blocked thread from procee.ling to execute code in the program that uses the resource. When the return code 35 from the operating system service for a`c~ ing synchronization mech~ni~m~ is t_e failure return code, the program will not proceed to the steps where it uses t_e resource that is protected by the synchronization mech~ni~m. RaLher, the operating system 21~862~
service for requesting syncl~o~ dLion merh~nisme will call the Op~dLillg system service for acquiring synchronization m~rh~nisme again in another attempt to acquire the synchronization meçh~niem Figure 4 is a flow diagram showing the steps carried out by the facility 5 304 when the sync_ronization mech~niem is released. The steps shown in Figure 4 are only executed if one or more threads are blocked on the synchLoni~dlion mech~niem when it is released. If zero thrcads are blocked on the syncl~lo~d~ion mech~nismwhen it is released, a synchru~ ion mech~niem be_aves like a cûnventional syncl~ùl~izdLion merh~niem In step 401, the facility 304 identifies the blocked thread 10 having the highest priority. If, in step 401, there are no bIocked threads, then these steps termin~te (not shown). If, in step 401, more than one blocked t~ead has the highest pnority, then the facility 304 selects one of the threads ~l~iLIdl;ly. In step 402, the facility 304 unblocks the identified thread. This involves calling the opeldLillg system to modify the ~minietrative information stored about the identified thread to 15 clear the blocked flag. This step also includes removing the identified thread from the list of threads that are blocked on the synchl~ alion merh~niem In step 403, if a thread has blocked on the synchronization device since the last time the synchlolli;~Lion device was acquired, then the facility 304 continues at step 404, else these steps conclude without pc. ,..i~l;..g any thread to acquire the ~y.,cLoniz~lion merh~ni~m The 20 facility 304 makes the cletPrmin~tion in step 403 by cherking a freshly blocked unflag that is set each time a thread blocks on the synchrol-i7;~l ;on m~rh~ni.em and cleared each time the syncl~olli;~Lion me~h~niem is released. In step 404, the facility 304 permits the iclentified thread to acquire the syllchrol~ization ll,ech~..;em Step 404 involves storing the thread as the owner of the syncl~o~ 1ion mech~niem This step also includes l~L~ g success to the opcl~Lillg system service for requesting ~yllchron~Lion me~h~nieme on return from the opclaLillg system service for acquiring synchloni~lion m~ch~nieme The Op~,ldlillg system se~vice for requesting ~yllcLol~i~LiOn m~h~nieme then returns success to the op~,ldLi~g system service for acquiring syncl~n-~Lion m~rh~nieme These steps then conclude.
Figure S is a timing diagram demon~Ll~Lil~g the advantages of the facility 304. The timing diagram contains timelines 501, 502, 503, and 504, which COrl~ s~ol-d to the activity of a first, secon~d, third, and fourth thread, lc~ye~;Li~ely. The four threads all have the same priority. For the convenience of the reader, the major events depicted in Figure S are listed below in chronological order in Table 3.
;
213~525 -time thread event 505 1 ~L~ L~ to acquire; p~ iLI~ to acquire 506 2 allel~ to acquire;blocks 512 3 ~LL~m~ to acquire; blocks 513 4 aLLc.ll~L~ to acquire; blocks 507 1 releases 508 2 unblocked; assigns ownership 509 2 releases 510 3 unblocked 511 1 aLL~ L~ to reacquire; p~ llecl to reacquire Table 3 The first thread lcc~ives the first time slice and s~lcces~fillly ~llclll~l~ to 5 acquire the synchronization mech~ni~m at tirne 505. Thereafter, the synchronization meçh~ni~m is owned by the first thread. The second thread gets the next time slice, during which it unsuccessfully ~LLem~L~ to acquire the synchronization me~h~ni~m at time 506. The second thread is th~.~dlL~. blocked as shown by the asterisk following the "At" label of the attempt to acquire event at time 506, the attempt to acquire causes 10 the facility to set the freshly blocked on flag. The third and fourth threads subsequently receive time slices and unsuccescfillly attempt to acquire the synchroni7~1;0n meçh~ni~m at times 512 and 513 respectively, and therefore block thereafter. Because the second, third and fourth threads are blocked, the first thread receives the next time slice. At time 507, the first thread releases the ~yllchl~l~i~Lion m. rh~ni~m The 15 facility checks whether the freshly blocked nnflag is set in step 403. It is, because no thread has acquiréd the synchronization me~h~ni~m since time 506 when the secondthread ~lLe~ led to acquire the synchloniz~lion mP~h~ni~m The circle around the "R"
label of the release event at time 507 shows that on release, the facility unblocks the second thread and assigns the sy-n,h,oni~lLion mech~ni~m to the second thread at time 20 508. The second thread thereafter owns the synchronization mech~ni~m, and may use it as soon as it receives the next time slice. In the foLcgoing, the first thread was plcvc~lled from monopolizing the sync~ollizaLion mech~ni~m for more than two of its conse~;ulive time slices.
During its time slice, the second thread releases the synchronization 25 mech~nicm at time 509. As shown by the rectangle around the "R" label of the release event at time 509, the freshly blocked unflag is not set and ~erefore the third thread is unblocked at time 510, but ~e s,~chronization mech~ni~m is not reassigned. This . .
permits the second thread to succeed at its attempt to lt~C~luiLe, the ~yllc~oni~Lion mer.h~ni.~m at time 511, later during the same time slice. In folegoillg, subsequent ~LLe111~ by the same thread to acquire the ~yucLo~ ;on mech~ni~m during the sametime slice do not cause an ~A~,~ive thread switch unless other threads have alL~ ed 5 to acquire the ~yllchro.~ ;on m~ch~ni~m during owning thread's ow.... ~1.ip While this invention has been shown and described with ~fe.e.lcc to prert;llcd embodiments, it will be mrlerstood by those skilled in the art that various changes or modifications in forrn and detail may be made without depar~g from the scope of the invention. For example, it could be used for any use regulation device in -, 10 which resource users are so. I~el ;l l.~s required to wait before they are p. . ", il~ecl to use a resource.
Claims (20)
1. A method in a computer system for managing ownership of a synchronization mechanism for synchronizing access to a resource with respect to a plurality of entities attempting to acquire the synchronization mechanism, the method comprising the steps of:
identifying one of the plurality of entities attempting to acquire the synchronization mechanism;
determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time;
if an entity has attempted to acquire the synchronization mechanism during the selected period of time, assigning ownership of the synchronization mechanism to the identified one of the plurality of entities; and if no entity has attempted to acquire the synchronization mechanism during the selected period of time, deferring the ownership of synchronization mechanism.
identifying one of the plurality of entities attempting to acquire the synchronization mechanism;
determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time;
if an entity has attempted to acquire the synchronization mechanism during the selected period of time, assigning ownership of the synchronization mechanism to the identified one of the plurality of entities; and if no entity has attempted to acquire the synchronization mechanism during the selected period of time, deferring the ownership of synchronization mechanism.
2. The method of claim 1 wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time determines whether any entity has attempted to acquire the synchronization mechanism during a selected period of time ending at a time contemporaneous with the occurrence of the determining step.
3. The method of claim 2, further including the steps of:
before the step of identifying one of the plurality of entities attempting to acquire the synchronization mechanism, permitting an entity to acquire the synchronization mechanism, and before the step of identifying one of the plurality of entities attempting to acquire the synchronization mechanism, permitting the entity that acquired the synchronization mechanism to release the synchronization mechanism; and wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time determines whether any entity has attempted to acquire the synchronization mechanism during a selected period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the entity.
before the step of identifying one of the plurality of entities attempting to acquire the synchronization mechanism, permitting an entity to acquire the synchronization mechanism, and before the step of identifying one of the plurality of entities attempting to acquire the synchronization mechanism, permitting the entity that acquired the synchronization mechanism to release the synchronization mechanism; and wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time determines whether any entity has attempted to acquire the synchronization mechanism during a selected period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the entity.
4. The method of claim 1, further including the step of, before the step of identifying one of the plurality of entities attempting to acquire the synchronization mechanism, permitting an entity to release the synchronization mechanism, and wherein the method occurs after the synchronization mechanism has been released by an entity, and wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time determines whether any entity has attempted to acquire the synchronization mechanism during a selected period of time ending at a time contemporaneous with the release of the synchronization mechanism by the entity.
5. The method of claim 4, further including the step of, before the step of permitting an entity to release the synchronization mechanism, permitting the entity to acquire the synchronization mechanism, and wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time determines whether any entity has attempted to acquire the synchronization mechanism during a selected period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the entity.
6. The method of claim 1 wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a selected period of time determines whether any entity has attempted to acquire the synchronization mechanism while the synchronization mechanism was owned by an entity that earlier acquired and released the synchronization mechanism.
7. The method of claim 1, further including the step of setting a flag to indicate whether any entity has attempted to acquire the synchronization mechanism during the selected period of time, and wherein the step of determining whether any entity has attempted to acquire the synchronization mechanism during a preselected period of time determines whether the flag has been set to indicate that an entity has attempted to acquire the synchronization mechanism during the preselected period of time.
8. A method of claim 1 wherein each of the plurality of entities is a thread.
9. The method of claim 1 wherein each of the plurality of entities is a process.
10. A method in a computer system for assigning the ownership of a synchronization mechanism for synchronizing use of a resource formerly acquired and released by a formerly owning thread to one of a plurality of threads presently attempting to acquire the synchronization mechanism, each of the plurality of threads presently attempting to acquire the synchronization mechanism having a priority indicator indicating the relative urgency of the thread's attempt to acquire the synchronization mechanism, the method comprising the steps of:
identifying the one of the plurality of threads presently attempting to acquire the synchronization mechanism having the priority indicator indicating the highest urgency;
determining whether any thread has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning thread acquired the synchronization mechanism and ending at the time that the formerly owning thread released the synchronization mechanism;
if a thread has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning thread acquired the synchronization mechanism and ending at the time that the formerly owning thread released the synchronization mechanism, assigning ownership of the synchronization mechanism to the identified one of the plurality of threads; and if no thread has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning thread acquired the synchronization mechanism and ending at the time that the formerly owning thread released the synchronization mechanism, deferring the assignment of ownership of the synchronization mechanism.
identifying the one of the plurality of threads presently attempting to acquire the synchronization mechanism having the priority indicator indicating the highest urgency;
determining whether any thread has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning thread acquired the synchronization mechanism and ending at the time that the formerly owning thread released the synchronization mechanism;
if a thread has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning thread acquired the synchronization mechanism and ending at the time that the formerly owning thread released the synchronization mechanism, assigning ownership of the synchronization mechanism to the identified one of the plurality of threads; and if no thread has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning thread acquired the synchronization mechanism and ending at the time that the formerly owning thread released the synchronization mechanism, deferring the assignment of ownership of the synchronization mechanism.
11. A method in a computer system for assigning the ownership of a synchronization mechanism for synchronizing use of a resource formerly acquired and released by a formerly owning process to one of a plurality of processes presently attempting to acquire the synchronization mechanism, each of the plurality of processes presently attempting to acquire the synchronization mechanism having a priority indicator indicating the relative urgency of the process's attempt to acquire the synchronization mechanism, the method comprising the steps of:
identifying the one of the plurality of processes presently attempting to acquire the synchronization mechanism having the priority indicator indicating the highest urgency;
determining whether any process has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning process acquired the synchronization mechanism and ending at the time that the formerly owning process released the synchronization mechanism;
if a process has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning process acquired the synchronization mechanism and ending at the time that the formerly owning process released the synchronization mechanism, assigning ownership of the synchronization mechanism to the identified one of the plurality of processes; and if no process has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning process acquired the synchronization mechanism and ending at the time that the formerly owning process released the synchronization mechanism, deferring the assignment of ownership of the synchronization mechanism.
identifying the one of the plurality of processes presently attempting to acquire the synchronization mechanism having the priority indicator indicating the highest urgency;
determining whether any process has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning process acquired the synchronization mechanism and ending at the time that the formerly owning process released the synchronization mechanism;
if a process has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning process acquired the synchronization mechanism and ending at the time that the formerly owning process released the synchronization mechanism, assigning ownership of the synchronization mechanism to the identified one of the plurality of processes; and if no process has attempted to acquire the synchronization mechanism during the period of time beginning at the time that the formerly owning process acquired the synchronization mechanism and ending at the time that the formerly owning process released the synchronization mechanism, deferring the assignment of ownership of the synchronization mechanism.
12. A method in a computer system for determining whether to reassign the ownership of a synchronization mechanism for synchronizing the use of a resource formerly acquired and released by a formerly owning thread to another thread presently attempting to acquire the synchronization mechanism, the method comprising the steps of:
determining whether any thread has attempted to acquire the synchronization mechanism during the period of time beginning at a time contemporaneous with theacquisition of the synchronization mechanism by the formerly owning thread and ending at a time contemporaneous with the release of the synchronization mechanism by the formerly owning thread;
if a thread has attempted to acquire the synchronization mechanism during the period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the formerly owning thread and ending at a time contemporaneous with the release of the synchronization mechanism by the formerly owning thread; and if no thread has attempted to acquire the synchronization mechanism during the period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the formerly owning thread and ending at a time contemporaneous with the release of the synchronization mechanism by the formerly owning thread, deferring the assignment of ownership of the synchronization mechanism
determining whether any thread has attempted to acquire the synchronization mechanism during the period of time beginning at a time contemporaneous with theacquisition of the synchronization mechanism by the formerly owning thread and ending at a time contemporaneous with the release of the synchronization mechanism by the formerly owning thread;
if a thread has attempted to acquire the synchronization mechanism during the period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the formerly owning thread and ending at a time contemporaneous with the release of the synchronization mechanism by the formerly owning thread; and if no thread has attempted to acquire the synchronization mechanism during the period of time beginning at a time contemporaneous with the acquisition of the synchronization mechanism by the formerly owning thread and ending at a time contemporaneous with the release of the synchronization mechanism by the formerly owning thread, deferring the assignment of ownership of the synchronization mechanism
13. A method in a computer system having a resource for determining whether to permit use of the resource by a selected requesting thread that is requesting to use the resource before the requesting thread next requests to use the resource, the selected requesting thread having a priority indicator that indicates the urgency of the request by the selected requesting thread to use the resource relative to the requests by other requesting threads to use the resource, the number of threads that may use the resource concurrently being limited to a predetermined maximum number of threads, the method comprising the steps of:
determining whether fewer than the predetermined maximum number of threads are presently using the resource;
if fewer than the predetermined maximum number of threads are presently using the resource and no other requesting threads are requesting to use the resource, immediately permitting use of the resource by the selected requesting thread;
if fewer than the predetermined maximum number of threads are presently using the resource and one or more other requesting threads are requesting to use the resource, determing whether the priority indicator of the selected thread indicates that the request by the selected thread to use the resource is more urgent than requests by the other requesting threads to use the resource;
if the priority indicator of the selected requesting thread indicates that the selected thread's request to use the resource is more urgent than requests by the other requesting threads to use the resource, determining whether the resource has been freshly blocked on;
if the resource has been freshly blocked on, immediately permitting the selected requesting thread to use the resource; and if the resource has not been freshly blocked on, omitting to immediately permit the selected requesting thread to use the resource.
determining whether fewer than the predetermined maximum number of threads are presently using the resource;
if fewer than the predetermined maximum number of threads are presently using the resource and no other requesting threads are requesting to use the resource, immediately permitting use of the resource by the selected requesting thread;
if fewer than the predetermined maximum number of threads are presently using the resource and one or more other requesting threads are requesting to use the resource, determing whether the priority indicator of the selected thread indicates that the request by the selected thread to use the resource is more urgent than requests by the other requesting threads to use the resource;
if the priority indicator of the selected requesting thread indicates that the selected thread's request to use the resource is more urgent than requests by the other requesting threads to use the resource, determining whether the resource has been freshly blocked on;
if the resource has been freshly blocked on, immediately permitting the selected requesting thread to use the resource; and if the resource has not been freshly blocked on, omitting to immediately permit the selected requesting thread to use the resource.
14. The method of claim 13 wherein the step of immediately permitting the selected requesting thread to use the resource if the resource has been freshly blocked on includes the steps of:
unblocking the selected requesting thread; and assigning ownership of a synchronization mechanism protecting the resource to the selected requesting thread.
unblocking the selected requesting thread; and assigning ownership of a synchronization mechanism protecting the resource to the selected requesting thread.
15. The method of claim 13 wherein the step of omitting to immediately permit the selected requesting thread to use the resource if the resource has not been freshly blocked on includes the step of unblocking the selected requesting thread without assigning ownership of a synchronization mechanism protecting the resource to the selected requesting thread.
16. A computer system for determining whether to assign the ownership of a synchronization mechanism for synchronizing the use of a resource to a thread, the computer system comprising:
a synchronization mechanism blocking monitor for determining whether any thread has blocked on the synchronization mechanism since the time the ownership of the synchronization mechanism was last assigned; and a synchronization mechanism ownership manager for assigning the ownership of a synchronization mechanism to a thread only if the synchronization mechanism blocking monitor determines that a thread has blocked on the synchronization mechanism since the time the ownership of the synchronization mechanism was last assigned.
a synchronization mechanism blocking monitor for determining whether any thread has blocked on the synchronization mechanism since the time the ownership of the synchronization mechanism was last assigned; and a synchronization mechanism ownership manager for assigning the ownership of a synchronization mechanism to a thread only if the synchronization mechanism blocking monitor determines that a thread has blocked on the synchronization mechanism since the time the ownership of the synchronization mechanism was last assigned.
17. A computer system for controlling the use of a resource by one or more threads, the computer system comprising:
a synchronization mechanism that may be acquired by a thread, permitting the thread to use the resource, and that may then be released by the thread, permitting the synchronization mechanism to be acquired by another thread;
a synchronization mechanism monitor for determining whether a thread has attempted to acquire the synchronization mechanism since the synchronization mechanism was last actually acquired; and an acquisition request arbiter for determining which, if any, of a group of blocked requesting threads may acquire the synchronization mechanism, the acquisition request arbiter including:
a requesting thread priority differentiator for determining which of the blocked requesting threads is the most important, a blocked requesting thread unblocker for unblocking the most important requesting thread, and an acquisition grantor that permits the unblocked thread to acquire the synchronization mechanism only if the synchronization mechanism monitor determines that a thread has attempted to acquire the synchronization mechanism since the synchronization mechanism was last actually acquired.
a synchronization mechanism that may be acquired by a thread, permitting the thread to use the resource, and that may then be released by the thread, permitting the synchronization mechanism to be acquired by another thread;
a synchronization mechanism monitor for determining whether a thread has attempted to acquire the synchronization mechanism since the synchronization mechanism was last actually acquired; and an acquisition request arbiter for determining which, if any, of a group of blocked requesting threads may acquire the synchronization mechanism, the acquisition request arbiter including:
a requesting thread priority differentiator for determining which of the blocked requesting threads is the most important, a blocked requesting thread unblocker for unblocking the most important requesting thread, and an acquisition grantor that permits the unblocked thread to acquire the synchronization mechanism only if the synchronization mechanism monitor determines that a thread has attempted to acquire the synchronization mechanism since the synchronization mechanism was last actually acquired.
18. The computer system of claim 17 wherein the synchronization mechanism is a critical section.
19. The computer system of claim 17 wherein the synchronization mechanism is a mutual exclusion mechanism.
20. The computer system of claim 17 wherein the synchronization mechanism is a semaphore.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/176,132 US5586318A (en) | 1993-12-23 | 1993-12-23 | Method and system for managing ownership of a released synchronization mechanism |
| US08/176,132 | 1993-12-23 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2138625A1 true CA2138625A1 (en) | 1995-06-24 |
Family
ID=22643112
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002138625A Abandoned CA2138625A1 (en) | 1993-12-23 | 1994-12-20 | Method and system for managing ownership of a released synchronization mechanism |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US5586318A (en) |
| EP (1) | EP0661633B1 (en) |
| JP (1) | JP3318455B2 (en) |
| CA (1) | CA2138625A1 (en) |
| DE (1) | DE69428972T2 (en) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5812844A (en) * | 1995-12-07 | 1998-09-22 | Microsoft Corporation | Method and system for scheduling the execution of threads using optional time-specific scheduling constraints |
| US5931923A (en) * | 1996-02-16 | 1999-08-03 | Advanced Micro Devices, Inc. | System for accessing control to a peripheral device utilizing a synchronization primitive within the peripheral device |
| US5835964A (en) * | 1996-04-29 | 1998-11-10 | Microsoft Corporation | Virtual memory system with hardware TLB and unmapped software TLB updated from mapped task address maps using unmapped kernel address map |
| US6424991B1 (en) | 1996-07-01 | 2002-07-23 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server communication framework |
| US6272555B1 (en) | 1996-07-01 | 2001-08-07 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system |
| US6266709B1 (en) | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
| US6304893B1 (en) | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US5987245A (en) | 1996-07-01 | 1999-11-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework |
| US5848246A (en) | 1996-07-01 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system |
| US6038590A (en) | 1996-07-01 | 2000-03-14 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system |
| US5999972A (en) | 1996-07-01 | 1999-12-07 | Sun Microsystems, Inc. | System, method and article of manufacture for a distributed computer system framework |
| US6434598B1 (en) | 1996-07-01 | 2002-08-13 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system |
| EP0834806B1 (en) * | 1996-08-28 | 2008-04-23 | Hitachi, Ltd. | Process executing method and resource accessing method in computer system |
| US6658447B2 (en) * | 1997-07-08 | 2003-12-02 | Intel Corporation | Priority based simultaneous multi-threading |
| US5987492A (en) | 1997-10-31 | 1999-11-16 | Sun Microsystems, Inc. | Method and apparatus for processor sharing |
| US6026427A (en) * | 1997-11-21 | 2000-02-15 | Nishihara; Kazunori | Condition variable to synchronize high level communication between processing threads |
| US6047316A (en) * | 1997-12-12 | 2000-04-04 | Intel Corporation | Multiprocessor computing apparatus having spin lock fairness |
| US6499048B1 (en) * | 1998-06-30 | 2002-12-24 | Sun Microsystems, Inc. | Control of multiple computer processes using a mutual exclusion primitive ordering mechanism |
| US6188411B1 (en) | 1998-07-02 | 2001-02-13 | Neomagic Corp. | Closed-loop reading of index registers using wide read and narrow write for multi-threaded system |
| US6920634B1 (en) * | 1998-08-03 | 2005-07-19 | International Business Machines Corporation | Detecting and causing unsafe latent accesses to a resource in multi-threaded programs |
| US7518993B1 (en) * | 1999-11-19 | 2009-04-14 | The United States Of America As Represented By The Secretary Of The Navy | Prioritizing resource utilization in multi-thread computing system |
| US6681384B1 (en) * | 1999-12-23 | 2004-01-20 | International Business Machines Corporation | Multi-threaded break-point |
| US6829609B1 (en) * | 2000-01-11 | 2004-12-07 | Emc Corporation | System, device, and method for providing mutual exclusion for computer system resources |
| US6829763B1 (en) * | 2000-05-16 | 2004-12-07 | Litton Systems, Inc. | Partitioned executive structure for real-time programs |
| GB0112571D0 (en) * | 2001-05-24 | 2001-07-18 | Ibm | Priority inversion in computer system supporting multiple processes |
| US20030074390A1 (en) * | 2001-10-12 | 2003-04-17 | Hudson Richard L. | Hardware to support non-blocking synchronization |
| US20030145035A1 (en) * | 2002-01-15 | 2003-07-31 | De Bonet Jeremy S. | Method and system of protecting shared resources across multiple threads |
| US7584219B2 (en) * | 2003-09-24 | 2009-09-01 | Microsoft Corporation | Incremental non-chronological synchronization of namespaces |
| US20050235015A1 (en) * | 2004-03-31 | 2005-10-20 | Microsoft Corporation | User-configurable device storage synchronization manager |
| GB2412761C (en) | 2004-04-02 | 2011-01-05 | Nokia Corp | Improvements in or relating to an operating system for a computing device |
| US20060235927A1 (en) * | 2005-04-19 | 2006-10-19 | Bhakta Dharmesh N | System and method for synchronizing distributed data streams for automating real-time navigation through presentation slides |
| GB0516474D0 (en) * | 2005-08-10 | 2005-09-14 | Symbian Software Ltd | Pre-emptible context switching in a computing device |
| KR100824792B1 (en) * | 2006-07-11 | 2008-04-24 | 삼성전자주식회사 | Command processing devices and method thereof, and systems having the same |
| WO2011066548A1 (en) * | 2009-11-30 | 2011-06-03 | Uvt Tech Systems, Inc. | Laser doping |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5159686A (en) * | 1988-02-29 | 1992-10-27 | Convex Computer Corporation | Multi-processor computer system having process-independent communication register addressing |
| EP0365728B1 (en) * | 1988-10-28 | 1993-12-29 | International Business Machines Corporation | Resource access for a multiprocessing computer system |
| EP0381655A3 (en) * | 1989-01-31 | 1992-12-02 | International Business Machines Corporation | Method for synchronizing the dispatching of tasks among multitasking operating systems |
| US5016166A (en) * | 1989-04-12 | 1991-05-14 | Sun Microsystems, Inc. | Method and apparatus for the synchronization of devices |
| US5187790A (en) * | 1989-06-29 | 1993-02-16 | Digital Equipment Corporation | Server impersonation of client processes in an object based computer operating system |
| US5179702A (en) * | 1989-12-29 | 1993-01-12 | Supercomputer Systems Limited Partnership | System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling |
| JPH04308961A (en) * | 1991-01-18 | 1992-10-30 | Ncr Corp | Means and apparatus for notifying state of synchronous locking of occupied process |
| US5247675A (en) * | 1991-08-09 | 1993-09-21 | International Business Machines Corporation | Preemptive and non-preemptive scheduling and execution of program threads in a multitasking operating system |
| GB9123264D0 (en) * | 1991-11-01 | 1991-12-18 | Int Computers Ltd | Semaphone arrangement for a data processing system |
| US5515538A (en) * | 1992-05-29 | 1996-05-07 | Sun Microsystems, Inc. | Apparatus and method for interrupt handling in a multi-threaded operating system kernel |
| US5438677A (en) * | 1992-08-17 | 1995-08-01 | Intel Corporation | Mutual exclusion for computer system |
-
1993
- 1993-12-23 US US08/176,132 patent/US5586318A/en not_active Expired - Lifetime
-
1994
- 1994-12-20 CA CA002138625A patent/CA2138625A1/en not_active Abandoned
- 1994-12-21 EP EP94120347A patent/EP0661633B1/en not_active Expired - Lifetime
- 1994-12-21 JP JP31812694A patent/JP3318455B2/en not_active Expired - Lifetime
- 1994-12-21 DE DE69428972T patent/DE69428972T2/en not_active Expired - Lifetime
-
1996
- 1996-09-19 US US08/715,937 patent/US5784618A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP0661633B1 (en) | 2001-11-07 |
| DE69428972T2 (en) | 2002-05-29 |
| JP3318455B2 (en) | 2002-08-26 |
| DE69428972D1 (en) | 2001-12-13 |
| US5784618A (en) | 1998-07-21 |
| EP0661633A1 (en) | 1995-07-05 |
| US5586318A (en) | 1996-12-17 |
| JPH07200323A (en) | 1995-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2138625A1 (en) | Method and system for managing ownership of a released synchronization mechanism | |
| US7752620B2 (en) | Administration of locks for critical sections of computer programs in a computer that supports a multiplicity of logical partitions | |
| US4104718A (en) | System for protecting shared files in a multiprogrammed computer | |
| US6272517B1 (en) | Method and apparatus for sharing a time quantum | |
| US6269391B1 (en) | Multi-processor scheduling kernel | |
| US5805900A (en) | Method and apparatus for serializing resource access requests in a multisystem complex | |
| US5630128A (en) | Controlled scheduling of program threads in a multitasking operating system | |
| US20060130062A1 (en) | Scheduling threads in a multi-threaded computer | |
| US5812844A (en) | Method and system for scheduling the execution of threads using optional time-specific scheduling constraints | |
| CN100568182C (en) | The method and system of distribution work in the data handling system of subregion logically | |
| US6101524A (en) | Deterministic replay of multithreaded applications | |
| US6449614B1 (en) | Interface system and method for asynchronously updating a share resource with locking facility | |
| US5247675A (en) | Preemptive and non-preemptive scheduling and execution of program threads in a multitasking operating system | |
| EP0747815B1 (en) | Method and apparatus for avoiding dealocks by serializing multithreaded access to unsafe resources | |
| US6779182B1 (en) | Real time thread dispatcher for multiprocessor applications | |
| US5956712A (en) | Byte range locking in a distributed environment | |
| EP0264568B1 (en) | Serialisation of system events in a multiprocessing system | |
| US6016490A (en) | Database management system | |
| EP1187019B1 (en) | Resource management | |
| US5251317A (en) | Computer system with an access control unit for resource | |
| US6662364B1 (en) | System and method for reducing synchronization overhead in multithreaded code | |
| EP1008934A2 (en) | Method and apparatus for user level monitor implementation | |
| EP0913770A2 (en) | Method and apparatus for sharing a time quantum | |
| US7454579B1 (en) | Managing access to shared resources | |
| JP2571260B2 (en) | Operating environment selection processing method using logic clock |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |