Techniques for synchronizing processing of at least two code threads

• US 8,752,057 B1
• Filed: 06/30/2008
• Issued: 06/10/2014
• Est. Priority Date: 06/30/2008
• Status: Active Grant

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: EMC Corporation (Dell Technologies Inc.)
• Inventors: Gould, Christopher M., McCann, Peter J.
• Primary Examiner(s): Fennema, Robert
• Assistant Examiner(s): Partridge, William B
• Application Number:
  US12/215,904
• Time in Patent Office: 2,171 Days
• Field of Search: None
• US Class Current: 718/102
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• CPC Class Codes: G06F 9/526 Mutual exclusion algorithms

Abstract

Described are techniques synchronizing processing of at least two code threads. A first thread executing in user space is provided. A second thread executing in kernel space is provided. A global mutex lock is provided for synchronizing processing between said first thread and said second thread. One of said first thread and said second thread holds the global mutex lock and is identified as a current owner of the global mutex lock. The other of said first thread and said second thread requests the global mutex lock and is blocked until the current owner of the global mutex lock releases the global mutex lock. The global mutex lock is held by at most one thread at a point in time and is identified as the current owner.

Claims

1. A method for synchronizing processing of at least two code threads comprising:

providing a first thread executing in user space;

providing a second thread executing in kernel space; and

providing a global mutex lock for synchronizing processing between said first thread and said second thread wherein one of said first thread and said second thread holds the global mutex lock and is identified as a current owner of the global mutex lock, and the other of said first thread and said second thread requests the global mutex lock and is blocked until the current owner of the global mutex lock releases the global mutex lock, wherein said global mutex lock is held by at most one thread at a point in time and is identified as the current owner, wherein said first thread initiates creation of the global mutex lock and a global mutex structure associated with the global mutex lock, the global mutex structure including a dirty indicator which is set to dirty when the current owner terminates abnormally prior to releasing the global mutex lock thereby terminating while holding the global mutex lock, wherein said dirty indicator is set to indicate that the current owner terminated abnormally to notify a subsequent owner of the global mutex lock that a resource previously used by the current owner may be left in an invalid or inconsistent state.

2. The method of claim 1, wherein said global mutex lock is used to synchronize processing between said first thread executing in a context of a first user space container, said second thread executing in a context of a kernel space container, and a third thread executing in a context of a second user space container different from said first user space container.

3. The method of claim 1, wherein said first thread is identified as creator of the global mutex lock and initiates creation of the global mutex lock by executing a first call to code associated with an application programming interface to create said global mutex lock.

4. The method of claim 3, wherein creating the global mutex lock in connection with said first call includes:

proxying a call from user space into kernel space to a third thread that performs processing to create the global mutex lock, said processing performed to create the global mutex lock including creating an operating system mutex lock in kernel space and tracking said first thread executing in a context of a first user space container as creator of the global mutex lock.

5. The method of claim 4, wherein said processing performed to create the global mutex lock includes creating and initializing the global mutex structure included in a list of global mutex structures, said global mutex structure including a first field identifying the current owner of the global mutex lock, a second field identifying the operating system mutex lock, the dirty indicator, and a reference count identifying a number of users of said global mutex lock.

6. The method of claim 5, wherein, prior to requesting the global mutex lock, an open call is made to open said global mutex lock, and wherein said number of users is an integer quantity formed as a sum of one, for a creator of said global mutex lock that executed said first call, and a number quantifying how many open calls are made to a point in time by threads currently executing in user space and kernel space for which no corresponding close call for said global mutex lock has been issued up to said first pointing time.

7. The method of claim 6, wherein, processing is performed to deallocate resources associated with said global mutex lock when said number of current users indicates that there are no current users of said global mutex lock.

8. The method of claim 5, wherein, upon termination of a user space container, processing is performed, said processing including:

identifying each global mutex structure in said list of global mutex structures for which said user space container is identified in the first field as the current owner, setting the dirty indicator of said each global mutex structure, and releasing the operating system mutex lock identified by said second field, said releasing causing selection of a blocked thread, if any, waiting to acquire a global mutex lock associated with said each global mutex structure to resume execution and acquire the operating system mutex lock identified by the second field to become the current owner.

9. The method of claim 8, wherein said processing performed upon termination of a user space container further includes:

identifying each global mutex structure in said list of global mutex structures for which said user space container is identified as creator and deallocating resources associated with said each global mutex lock when said number of current users of said each global mutex lock indicates that there are no current users of said each global mutex lock.

10. The method of claim 1, wherein the current owner of the global mutex is identified using information identifying a container and a thread, said container being a user space or a kernel space fault domain including said thread.

11. The method of claim 1, wherein said first thread acquires the global mutex lock and becomes the current global mutex lock owner by issuing a call using a first defined interface and said second thread requests the global mutex lock by issuing a call using the first defined interface.

12. The method of claim 1, further comprising:

requesting and obtaining the global mutex lock by the first thread, the first thread being identified as the current owner of the global mutex lock;

requesting the global mutex lock by the second thread while the global mutex lock is owned by the first thread, wherein said requesting by the second thread causes execution of the second thread to be blocked because another thread currently owns the global mutex lock; and

releasing, by the first thread, the global mutex lock so that the global mutex lock has no current owner, wherein said releasing causes the second thread to resume execution and acquire the global mutex lock, said second thread being identified as the current owner of the global mutex lock.

13. The method of claim 1, wherein all global mutex locks created by threads executing in user space and kernel space are resources associated with a logical device included in kernel space.

14. The method of claim 1, wherein said first thread and said second thread perform calls using a same interface to perform operations in connection with global mutex locks including said global mutex lock, said same interface including a first interface to create a global mutex lock, a second interface to destroy a global mutex lock, a third interface to open a global mutex lock, a fourth interface to close a global mutex lock, a fifth interface to request a global mutex lock, and a sixth interface to release a global mutex lock.

15. The method of claim 1, further comprising:

requesting and obtaining the global mutex lock by the first thread, the first thread being identified as the current owner of the global mutex lock;

requesting the global mutex lock by the second thread while the global mutex lock is owned by the first thread, wherein said requesting by the second thread causes execution of the second thread to be blocked because another thread currently owns the global mutex lock;

and wherein a user space container including said first thread terminates, and in response to the first thread terminating, processing is performed, said processing including;

marking an indicator associated with said global mutex lock indicating that the current owner of the global mutex lock terminated while holding the global mutex lock;

releasing the global mutex lock; and

causing said second thread to resume execution and acquire the global mutex lock, said second thread being identified as the current owner of the global mutex lock, wherein said second thread is notified in accordance with said indicator that said global mutex lock was released as a result of a previous owner of the global mutex lock terminating while holding the global mutex lock.

16. A non-transitory computer readable medium comprising executable code stored thereon for synchronizing processing of at least two code threads, the computer readable medium comprising executable code for:

providing a first thread executing in user space;

providing a second thread executing in kernel space; and

providing a global mutex lock for synchronizing processing between said first thread and said second thread wherein one of said first thread and said second thread holds the global mutex lock and is identified as a current owner of the global mutex lock, and the other of said first thread and said second thread requests the global mutex lock and is blocked until the current owner of the global mutex lock releases the global mutex lock, wherein said global mutex lock is held by at most one thread at a point in time and is identified as the current owner, wherein said first thread initiates creation of the global mutex lock and a global mutex structure associated with the global mutex lock, the global mutex structure including a dirty indicator which is set to dirty when the current owner terminates abnormally prior to releasing the global mutex lock thereby terminating while holding the global mutex lock, wherein said dirty indicator is set to indicate that the current owner terminated abnormally to notify a subsequent owner of the global mutex lock that a resource previously used by the current owner may be left in an invalid or inconsistent state.

17. The non-transitory computer readable medium of claim 16, wherein said global mutex lock is used to synchronize processing between said first thread executing in a context of a first user space container, said second thread executing in a context of a kernel space container, and a third thread executing in a context of a second user space container different from said first user space container.

18. The non-transitory computer readable medium of claim 16, wherein all global mutex locks created by threads executing in user space and kernel space are resources associated with a logical device included in kernel space.

19. The non-transitory computer readable medium of claim 16, wherein said first thread and said second thread perform calls using a same interface to perform operations in connection with global mutex locks including said global mutex lock, said same interface including a first interface to create a global mutex lock, a second interface to destroy a global mutex lock, a third interface to open a global mutex lock, a fourth interface to close a global mutex lock, a fifth interface to request a global mutex lock, and a sixth interface to release a global mutex lock.

20. The non-transitory computer readable medium of claim 16, further comprising executable code for:

requesting and obtaining the global mutex lock by the first thread, the first thread being identified as the current owner of the global mutex lock;

requesting the global mutex lock by the second thread while the global mutex lock is owned by the first thread, wherein said requesting by the second thread causes execution of the second thread to be blocked because another thread currently owns the global mutex lock;

and wherein a user space container including said first thread terminates, and in response to the first thread terminating, processing is performed, said processing including;

marking an indicator associated with said global mutex lock indicating that the current owner of the global mutex lock terminated while holding the global mutex lock;

releasing the global mutex lock; and

causing said second thread to resume execution and acquire the global mutex lock, said second thread being identified as the current owner of the global mutex lock, wherein said second thread is notified in accordance with said indicator that said global mutex lock was released as a result of a previous owner of the global mutex lock terminating while holding the global mutex lock.