Method for managing concurrent processes using dual locking

• US 6,401,110 B1
• Filed: 11/30/1998
• Issued: 06/04/2002
• Est. Priority Date: 11/30/1998
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Freitas, Richard Francis, Jadav, Divyesh, Kenchammana-Hosekote, Deepak, Strong, Hovey Raymond Jr., Menon, Jaishankar Moothedath
• Primary Examiner(s): Burgess, Glenton B.
• Assistant Examiner(s): EDELMAN, BRADLEY E
• Application Number:
  US09/203,101
• Publication Number:
  US 20020052959A1
• Time in Patent Office: 1,282 Days
• Field of Search: 709/229, 709/104, 709/107, 709/106, 709/203, 709/102, 709/224, 709/226, 709/213
• US Class Current: 718/104
• CPC Class Codes: G06F 2209/522 Manager
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

Multiple competing processors cooperatively manage access to a shared resource. Each processor separately stores a lock table, listing shared resource subparts, such as memory addresses of a data storage device, for example. The lock tables are stored in nonvolatile storage. In each lock table, each subpart is associated with a “state,” such as; LOCAL or REMOTE. In response to access requests from the hosts, the processors exchange various messages to cooperatively elect a single processor to have exclusive access to the subparts involved in the access requests. After one processor is elected, the lock-holding processor configures its lock table to show the identified subpart in the LOCAL state, and all non-lock-holding processors configure their lock tables to show the identified subpart in the REMOTE state. Thus, rather than replicating one lock table for all processors, the processors separately maintain lock tables that are coordinated with each other. Importantly, each processor honors its lock table by refraining from accessing a subpart of the shared resource unless the processor'"'"'s lock table indicates a LOCAL state for that subpart. In one embodiment, optimized for the two processor environment, the messages exchanged by the processors include lock request, lock release, and lock grant messages.

Claims

1. A method for managing access to a shared resource in a computing system, including multiple processors each coupled to the shared resource, the processors being coupled to one or more hosts, the method comprising operations of:

each processor separately storing a corresponding lock table listing one or more subparts of the shared resource, where each lock table also lists in association with each subpart a state selected from a state group including a LOCAL state and a REMOTE state;

in response to an access request from one of the hosts, the access request identifying one or more subparts of the shared resource, the processors awarding a lock on all identified subparts by electing a single processor to have exclusive access to the identified subparts;

wherein the awarding of a lock for one or more subparts comprises the processors exchanging one or more messages from a group including lock request and lock grant, each lock request message including a newly generated token to distinguish the lock request from other lock requests, each lock grant message including a token from a lock request being granted thereby;

wherein the exchanging of messages comprises each processor applying predetermined operations to cooperate with other processors in awarding locks, the predetermined operations comprising;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE state associated with specified subpart, the receiving processor returning a lock grant message including a token from a lock grant message originally granting a lock on the specified subpart causing the shared resource to enter the REMOTE state;

in response to the election, at a first time all non-lock-holding processors configuring their lock tables to show the identified subparts in the REMOTE state, and no earlier then the first time the lock-holding processor configuring its lock table to show the identified subpart in the LOCAL state; and

each processor refraining from accessing a subpart of the shared resource unless the processor'"'"'s lock table indicates a LOCAL state for that subpart.

2. The method of claim 1, the lock-holding processor configuring its lock table to show the identified subpart in the LOCAL state after the first time.

3. The method of claim 1, each processor storing its corresponding lock table in non-volatile storage.

4. The method of claim 1, the shared resource comprising one or more digital data storage devices.

5. The method of claim 1, the processors of the system being two in number.

6. The method of claim 1, the processors of the system being two in number, and including first and second processors, the electing operation including:

responsive to the first processor receiving a request to access a particular subpart, where the first processor'"'"'s lock table indicates a REMOTE state for that subpart, the first processor transmitting a lock request message to the second processor;

responsive to receipt of a lock request message concerning the subpart, the second processor configuring its lock table to indicate the REMOTE state for the identified subpart and then transmitting a lock grant message to the first processor; and

responsive to receipt of a lock grant message concerning the subpart, the first processor configuring its lock table to show a LOCAL state for the identified subpart.

7. The method of claim 6, and the operations further comprise:

the first processor determining whether tokens of the lock request and lock grant messages match, and if not, aborting the operation of configuring the first processor'"'"'s lock table to show a LOCAL state for the subpart.

8. The method of claim 1, where the state group further includes a FREE state.

9. The method of claim 8, where the electing operation further includes:

responsive to a processor completing access to a subpart of the shared resource, the processor transmitting a lock release message to the other processors, and then each processor configuring its lock table to indicate the FREE state for the subpart.

10. The method of claim 9, where the configuring of the lock table to indicate the FREE state comprises the processor removing the representation of the subpart from the lock table.

11. The method of claim 8, the processors of the system being two in number, and including first and second processors, the electing operation comprising:

the first processor transmitting a lock request message to the second processor, the lock request naming the identified subpart of the shared resource;

the second processor consulting its lock table to determine the state of the identified subpart, and in response to the lock table indicating a FREE state of the subpart, the second processor transmitting a lock grant message to the first processor, and then configuring the second processor'"'"'s lock table to show a REMOTE state for the identified subpart; and

the first processor receiving the lock grant message, and in response configuring the first processor'"'"'s lock table to show a LOCAL state for the identified subpart.

12. The method of claim 1, the processors of the system being two in number, and including first and second processors, the electing operation including:

responsive to the first processor receiving a request to access a particular subpart, where the first processor'"'"'s lock table indicates a REMOTE state for that subpart, the first processor transmitting a lock request message to the second processor;

responsive to the first processor failing to receive a lock grant message within a predetermined time, the first processor retransmitting the lock request message to the second processor.

13. The method of claim 1, the processors of the system being two in number, and including first and second processors, the electing operation including:

responsive to the first processor receiving a request to access a subpart, where the first processor'"'"'s lock table indicates a REMOTE state for that subpart, the first processor transmitting a lock request message to the second processor;

responsive to the lock request message, the second processor representing the lock request in a queue;

the second processor sequentially processing queued messages, and upon reaching the queued lock request, the second processor configuring its lock table to indicate the REMOTE state for the subpart and then transmitting a lock grant message to the first processor; and

responsive to receipt of a lock grant message concerning an identified subpart, the first processor configuring its lock table show a LOCAL state for the identified subpart.

14. The method of claim 1, the processors being two in number, and including first and second processors, the operations further comprising:

responsive to the first processor receiving a host request to access a first subpart of the shared resource while the lock table of the first processor shows the first subpart in the REMOTE state, the first processor transmitting a lock request message to the second processor in association with the first subpart.

15. The method of claim 14, further comprising:

the first processor retransmitting the lock request to the second processor according to a predetermined schedule until the second processor grants the requested lock on the first subpart.

16. The method of claim 14, where:

each processor maintains a queue of pending operations; and

responsive to the lock request, the second processor places a representation of the lock request in the queue of the second processor.

17. The method of claim 1, where:

the processors maintain respective queues of pending operations, and where each processor is responsive to host requests to access a subpart of the shared resource while the lock table of the processor shows the subpart in the REMOTE state by sending a lock request message to the other processors; and

the electing operation comprises, responsive to a processor'"'"'s receipt of an access request from one of the hosts involving a first subpart of the shared resource, determining whether the lock table of the processor lists the subpart in the LOCAL state and the processor'"'"'s queue is free from any lock requests from other processors, and if so, the processor proceeding to satisfy the host access request without sending any messages to the other processor.

18. The method of claim 1, further comprising:

in response to a processor receiving a host access request, the processor setting a timer, satisfied by completion of the host access request; and

responsive to unsatisfied expiration of the timer, the processor aborting the host access request.

19. The method of claim 1, where:

the processors maintain respective sequential queues of pending operations;

the processors are two in number, and include first and second processors, one of the processors being predesignated as a winner and the other being predesignated as a loser; and

responsive to each processor receiving a lock request from the other processor, where each processor has sent an unsatisfied lock request to the other processor, the loser processor granting a lock on the subpart to the winner processor, and the winner processor waiting for the lock grant and enqueing the loser processor'"'"'s lock request.

20. The method of claim 1,

where the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the predetermined operations further comprise;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a FREE state associated with specified subpart, the receiving processor returning a lock grant message including the associated token, updating the processor'"'"'s lock table to list the specified subpart in association with the REMOTE state and the associated token;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REQ state associated with specified subpart, the receiving processor participating in a predetermined dispute resolution procedure against a processor that submitted the lock request message, and

if the processor wins the procedure, placing the received lock in queue for later handling by the receiving processor;

if the processor loses the procedure, the receiving processor returning a lock grant message including the associated token, updating the processor'"'"'s lock table to indicate the, updating the processor'"'"'s lock table to list the specified subpart in association with the REMOTE state and in association with the associated token;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a LOCAL state associated with specified subpart, the receiving processor placing the received lock in queue for later handling by the receiving processor.

21. The method of claim 1,

where the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the predetermined operations further comprise;

responsive to a processor receiving from each other processor at least one lock grant message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REQ state associated with specified subpart, the receiving processor performing operations comprising;

if each of the associated tokens matches the token for the specified subpart shown in the lock table, commencing the host access request and updating the processor'"'"'s lock table to list the specified subpart in association with the LOCAL state and the associated token;

if the associated token does not match the token for the specified subpart shown in the lock table, sending a lock release message identifying the specified subpart and the associated token;

responsive to a processor receiving a lock grant message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE or FREE state associated with specified subpart, the receiving processor sending a lock release message identifying the specified subpart and the associated token.

22. The method of claim 1,

where the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the predetermined operations further comprise, responsive to a processor receiving a lock release message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE state associated with specified subpart, the receiving processor performing operations comprising;

only if the associated token does not match the token for the specified subpart shown in the lock table, the receiving processor returning a lock grant message including the token for the specified subpart shown in the lock table.

23. A signal-bearing medium tangibly embodying a program of machine-readable instructions executable by a digital data processing machine to perform operations to manage one processor in a multiple processor computing system, the processors having access to a shared resource, the operations comprising:

the processor storing a lock table listing one or more subparts of the shared resource, the lock table also listing in association with each subpart a state selected from a state group including a LOCAL state and a REMOTE state;

in response to an access request from one of the hosts, the access request identifying one or more subparts of the shared resource, the processor cooperating with the other processors to award a lock on all identified subparts by electing a single processor to have exclusive access to the identified subparts;

wherein the awarding of a lock for one or more subparts comprises the processors exchanging one or more messages from a group including lock request and lock grant, each lock request message including a newly generated token to distinguish the lock request from other lock requests, each lock grant message including a token from a lock request being granted thereby;

wherein the exchanging of messages comprises each processor applying predetermined operations to cooperate with other processors in awarding locks, the predetermined operations comprising;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE state associated with specified subpart, the receiving processor returning a lock grant message including a token from a lock grant message originally granting a lock on the specified subpart causing the shared resource to enter the REMOTE state;

in response to the election,

if the processor is not elected, the processor configuring its lock table to show the identified subpart in the REMOTE state;

if the processor is elected, the processor configuring its lock table to show the identified subpart in the LOCAL state; and

the processor refraining from accessing a subpart of the shared resource unless the processor'"'"'s lock table indicates the LOCAL state for that subpart.

24. The medium of claim 23, the processor storing its lock table in non-volatile storage.

25. The medium of claim 23, the shared resource comprising one or more digital data storage devices.

26. The medium of claim 23, the processors of the system being two in number.

27. The medium of claim 23, where the state group further includes a FREE state.

28. The medium of claim 23,

where the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the predetermined operations further comprise;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a FREE state associated with specified subpart, the receiving processor returning a lock grant message including the associated token, updating the processor'"'"'s lock table to list the specified subpart in association with the REMOTE state and the associated token;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REQ state associated with specified subpart, the receiving processor participating in a predetermined dispute resolution procedure against a processor that submitted the lock request message, and

if the processor wins the procedure, placing the received lock in queue for later handling by the receiving processor;

if the processor loses the procedure, the receiving processor returning a lock grant message including the associated token, updating the processor'"'"'s lock table to indicate the, updating the processor'"'"'s lock table to list the specified subpart in association with the REMOTE state and in association with the associated token;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a LOCAL state associated with specified subpart, the receiving processor placing the received lock in queue for later handling by the receiving processor.

29. The medium of claim 23,

where the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the predetermined operations further comprise;

responsive to a processor receiving from each other processor at least one lock grant message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REQ state associated with specified subpart, the receiving processor performing operations comprising;

if each of the associated tokens matches the token for the specified subpart shown in the lock table, commencing the host access request and updating the processor'"'"'s lock table to list the specified subpart in association with the LOCAL state and the associated token;

if the associated token does not match the token for the specified subpart shown in the lock table, sending a lock release message identifying the specified subpart and the associated token;

responsive to a processor receiving a lock grant message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE or FREE state associated with specified subpart, the receiving processor sending a lock release message identifying the specified subpart and the associated token.

30. The medium of claim 23,

where the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the predetermined operations further comprise, responsive to a processor receiving a lock release message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE state associated with specified subpart, the receiving processor performing operations comprising;

only if the associated token does not match the token for the specified subpart shown in the lock table, the receiving processor returning a lock grant message including the token for the specified subpart shown in the lock table.

31. A multiple processor computing system, comprising:

a shared resource having multiple subparts; and

multiple processors coupled to one or more hosts, each processor being coupled to the shared resource, where the processors are programmed to perform operations to cooperatively utilize the resource, the operations comprising;

each processor separately storing a corresponding lock table listing one or more subparts of the shared resource, where each lock table also lists in association with each subpart a state selected from a state group including a LOCAL state and a REMOTE state;

in response to an access request from one of the hosts, the processors awarding a lock on all identified subparts by electing a single processor to have exclusive access to the identified subparts;

wherein the awarding of a lock for one or more subparts comprises the processors exchanging one or more messages from a group including lock request and lock grant, each lock request message including a newly generated token to distinguish the lock request from other lock requests, each lock grant message including a token from a lock request being granted thereby;

wherein the exchanging of messages comprises each processor applying predetermined operations to cooperate with other processors in awarding locks, the predetermined operations comprising;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE state associated with specified subpart, the receiving processor returning a lock grant message including a token from a lock grant message originally granting a lock on the specified subpart causing the shared resource to enter the REMOTE state;

in response the election, at a first time all non-lock-holding processors configuring their lock tables to show the identified subparts in the REMOTE state, and no earlier then the first time the lock-holding processor configuring its lock table to show the identified subpart in the LOCAL state; and

each processor refraining from accessing a subpart of the shared resource unless the processor'"'"'s lock table indicates a LOCAL state for that subpart.

32. The system of claim 31, the lock-holding processor configuring its lock table to show the identified subpart in the LOCAL state after the first time.

33. The system of claim 31, each processor storing its corresponding lock table in non-volatile storage.

34. The system of claim 31, the shared resource comprising one or more digital data storage devices.

35. The system of claim 31, the processors of the system being two in number.

36. The system of claim 31, the processors of the system being two in number, and including first and second processors, the electing operation including:

responsive to the first processor receiving a request to access a particular subpart, where the first processor'"'"'s lock table indicates a REMOTE state for that subpart, the first processor transmitting a lock request message to the second processor;

responsive to receipt of a lock request message concerning the subpart, the second processor configuring its lock table to indicate the REMOTE state for the subpart and then transmitting a lock grant message to the first processor; and

responsive to receipt of a lock grant message concerning an identified subpart, the first processor configuring its lock table to show a LOCAL state for the identified subpart.

37. The system of claim 36, where the operations further comprise:

the first processor determining whether tokens of the lock request and lock grant messages match, and if not, aborting the operation of configuring the first processor'"'"'s lock table to show a LOCAL state for the subpart.

38. The system of claim 31, where the state group further includes a FREE state.

39. The system of claim 38, where the electing operation further includes:

responsive to a processor completing access to a subpart of the shared resource, the processor transmitting a lock release message to the other processors, and then each processor configuring its lock table to indicate the FREE state for the subpart.

40. The system of claim 39, where the configuring of the lock table to indicate the FREE state comprises the processor removing the representation of the subpart from the table.

41. The system of claim 38, the processors being two in number, and including first and second processors, the electing operation comprising:

the first processor transmitting a lock request message to the second processor, the lock request naming the identified subpart of the shared resource;

the second processor consulting its lock table to determine the state of the identified subpart, and in response to the lock table indicating a FREE state of the subpart, the second processor transmitting a lock grant message to the first processor, and then configuring the second processor'"'"'s lock table to show a REMOTE state for the identified subpart; and

the first processor receiving the lock grant message, and in response configuring the first processor'"'"'s lock table to show a LOCAL state for the identified subpart.

42. The system of claim 31, the processors of the system being two in number, and including first and second processors, the electing operation including:

responsive to the first processor receiving a request to access a particular subpart, where the first processor'"'"'s lock table indicates a REMOTE state for that subpart, the first processor transmitting a lock request message to the second processor;

responsive to the first processor failing to receive a lock grant message within a predetermined time, the first processor retransmitting the lock request message to the second processor.

43. The system of claim 31, the processors being two in number, and including first and second processors, the electing operation including:

responsive to the first processor receiving a request to access a subpart, where the first processor'"'"'s lock table indicates a REMOTE state for that subpart, the first processor transmitting a lock request message to the second processor;

responsive to the lock request message, the second processor representing the lock request in a queue;

the second processor sequentially processing queued messages, and upon reaching the queued lock request, the second processor configuring its lock table to indicate the REMOTE state for the subpart and then transmitting a lock grant message to the first processor; and

responsive to receipt of a lock grant message concerning an identified subpart, the first processor configuring its lock table show a LOCAL state for the identified subpart.

44. The system of claim 31, the processors being two in number, and including first and second processors, the operations further comprising:

responsive to the first processor receiving a host request to access a first subpart of the shared resource while the lock table of the first processor shows the first subpart in the REMOTE state, the first processor transmitting a lock request message to the second processor in association with the first subpart.

45. The system of claim 44, the operations further comprising:

the first processor retransmitting the lock request to the second processor according to a predetermined schedule until the second processor grants the requested lock on the first subpart.

46. The system of claim 44, where:

each processor maintains a queue of pending operations; and

responsive to the lock request, the second processor places a representation of the lock request in the queue of the second processor.

47. The system of claim 31, where:

the processors maintain respective queues of pending operations, and where each processor is responsive to host requests to access a subpart of the shared resource while the lock table of the processor shows the subpart in the REMOTE state by sending a lock request message to the other processors; and

the electing operation comprises, responsive to a processor'"'"'s receipt of an access request from one of the hosts involving a first subpart of the shared resource, determining whether the lock table of the processor lists the subpart in the LOCAL state and the processor'"'"'s queue is free from any lock requests from other processors, and if so, the processor proceeding to satisfy the host access request without sending any messages to the other processor.

48. The system of claim 31, the operations further comprising:

in response to a processor receiving a host access request, the processor setting a timer, satisfied by completion of the host access request; and

responsive to unsatisfied expiration of the timer, the processor aborting the host access request.

49. The system of claim 31, where:

the processors maintain respective sequential queues of pending operations;

the processors are two in number, and include first and second processors, one of the processors being predesignated as a winner and the other being predesignated as a loser; and

responsive to each processor receiving a lock request from the other processor, where each processor has sent an unsatisfied lock request to the other processor, the loser processor issuing a lock on the subpart to the winner processor, and the winner processor waiting for the lock grant and enqueing the loser processor'"'"'s lock request.

50. The system of claim 31,

where the processors are programmed such that the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the processors are programmed such that the predetermined operations further comprise;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a FREE state associated with specified subpart, the receiving processor returning a lock grant message including the associated token, updating the processor'"'"'s lock table to list the specified subpart in association with the REMOTE state and the associated token;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REQ state associated with specified subpart, the receiving processor participating in a predetermined dispute resolution procedure against a processor that submitted the lock request message, and

if the processor wins the procedure, placing the received lock in queue for later handling by the receiving processor;

if the processor loses the procedure, the receiving processor returning a lock grant message including the associated token, updating the processor'"'"'s lock table to indicate the, updating the processor'"'"'s lock table to list the specified subpart in association with the REMOTE state and in association with the associated token;

responsive to a processor receiving a lock request message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a LOCAL state associated with specified subpart, the receiving processor placing the received lock in queue for later handling by the receiving processor.

51. The system of claim 31,

where the processors are programmed such that the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the processors are programmed such that the predetermined operations further comprise;

responsive to a processor receiving from each other processor at least one lock grant message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REQ state associated with specified subpart, the receiving processor performing operations comprising;

if each of the associated tokens matches the token for the specified subpart shown in the lock table, commencing the host access request and updating the processor'"'"'s lock table to list the specified subpart in association with the LOCAL state and the associated token;

if the associated token does not match the token for the specified subpart shown in the lock table, sending a lock release message identifying the specified subpart and the associated token;

responsive to a processor receiving a lock grant message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE or FREE state associated with specified subpart, the receiving processor sending a lock release message identifying the specified subpart and the associated token.

52. The system of claim 31,

where the processors are programmed such that the operation of storing lock tables is performed such that each lock table lists in association with each subpart:

a token;

a state selected from a state group including LOCAL, REQ, FREE, REMOTE;

wherein the processors are programmed such that the predetermined operations further comprise, responsive to a processor receiving a lock release message and associated token concerning a specified subpart of the shared resource when the receiving processor'"'"'s lock table shows a REMOTE state associated with specified subpart, the receiving processor performing operations comprising;

only if the associated token does not match the token for the specified subpart shown in the lock table, the receiving processor returning a lock grant message including the token for the specified subpart shown in the lock table.