IP Library › Granted Patent US 10,565,024
Granted Patent B2
US 10,565,024 · App. 15/298,090 · Granted Feb 18, 2020

Generic concurrency restriction

Inventors: David Dice (Foxboro, MA); Alex Kogan (Needham, MA)
Assignee: Oracle International Corporation
G06F9/52G06F9/5022G06F9/524
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,565,024
App. No.
15/298,090
Granted
Feb 18, 2020
Kind
B2
Abstract

Generic Concurrency Restriction (GCR) may divide a set of threads waiting to acquire a lock into two sets: an active set currently able to contend for the lock, and a passive set waiting for an opportunity to join the active set and contend for the lock. The number of threads in the active set may be limited to a predefined maximum or even a single thread. Generic Concurrency Restriction may be implemented as a wrapper around an existing lock implementation. Generic Concurrency Restriction may, in some embodiments, be unfair (e.g., to some threads) over the short term, but may improve the overall throughput of the underlying multithreaded application via passivation of a portion of the waiting threads.

Claims (74)

1. A method, comprising:

performing by a computer:

beginning execution of a multithreaded application that comprises a plurality of requests to acquire a lock associated with a critical section of code or a shared resource;

invoking, by a given thread of the application, a lock function of a generic concurrency restriction library, wherein the generic concurrency restriction library is configured to manage access to the lock;

determining, by the generic restriction library, whether the given thread should be placed in an active set of threads associated with the lock, wherein threads in the active set are able to contend for the lock;

in response to determining that the given thread should be placed in the active set, the given thread joining the active set of threads and contending for the lock, wherein joining the active set of threads comprises setting a lock flag accessible to other threads of the multithreaded application to indicate that the lock is held;

in response to determining that the given thread should not be placed in the active set, the given thread joining a passive set of threads, wherein threads in the passive set are not able to contend for the lock;

monitoring, by one or more passive threads in the passive set, the lock flag and the number of threads in the active set; and

in response to determining, based on said monitoring, to activate a passive thread in the passive set, one of the passive threads in the passive set joining the active set.

2. The method of claim 1 , further comprising:

determining, by an active thread in the active set, whether to activate another passive thread in the passive set;

setting, by the active thread in response to determining to activate the other passive thread, an activation signal to indicate that the other passive thread should be activated; and

joining, by the other passive thread in response to the activation signal being set, the active set, wherein after joining the active set the other passive thread is able to contend for the lock.

3. The method of claim 1 , wherein joining the active set of threads comprises:

invoking, by the given thread, an underlying lock function of the lock;

setting a lock flag to indicate that the lock is held, wherein the lock flag is accessible to other threads of the multithreaded application;

exiting the invoked lock function of the generic concurrency restriction library; and

wherein said setting is performed subsequent to said invoking and wherein said exiting is performed subsequent to said setting.

4. The method of claim 3 , further comprising:

invoking, by the given thread, an unlock function of the generic concurrency restriction library;

performing, by the given thread, while executing the invoked unlock function:

resetting the lock flag to indicate that the lock is not held; and

invoking an underlying unlock function of the lock, wherein said resetting is performed prior to said invoking.

5. The method of claim 1 , wherein said determining is based, at least in part, on a number of threads currently in the active set.

6. The method of claim 5 , wherein said determining is based, at least in part, on determining whether the number of threads currently in the active set is less than one.

7. A system, comprising:

a processor; and

a memory, comprising program instructions that when executed by the processor cause the processor to perform:

beginning execution of a multithreaded application that comprises a plurality of requests to acquire a lock associated with a critical section of code or a shared resource;

invoking, by a given thread of the application, a lock function of a generic concurrency restriction library, wherein the generic concurrency restriction library is configured to manage access to the lock;

determining, by the generic restriction library, whether the given thread should be placed in an active set of threads associated with the lock, wherein threads in the active set are able to contend for the lock;

in response to determining that the given thread should be placed in the active set, the given thread joining the active set of threads and contending for the lock, wherein joining the active set of threads comprises setting a lock flag accessible to other threads of the multithreaded application to indicate that the lock is held;

in response to determining that the given thread should not be placed in the active set, the given thread joining a passive set of threads, wherein threads in the passive set are not able to contend for the lock;

monitoring, by one or more passive threads in the passive set, the lock flag and the number of threads in the active set; and

in response to determining, based on said monitoring, to activate a passive thread in the passive set, one of the passive threads in the passive set joining the active set.

8. The system of claim 7 , wherein the program instructions further cause the processor to perform:

determining, by an active thread in the active set, whether to activate another passive thread in the passive set;

setting, by the active thread in response to determining to activate the other passive thread, an activation signal to indicate that the other passive thread should be activated; and

joining, by the other passive thread in response to the activation signal being set, the active set, wherein after joining the active set the other passive thread is able to contend for the lock.

9. The system of claim 7 , wherein joining the active set of threads comprises:

invoking, by the given thread, an underlying lock function of the lock;

setting a lock flag to indicate that the lock is held, wherein the lock flag is accessible to other threads of the multithreaded application;

exiting the invoked lock function of the generic concurrency restriction library; and

wherein said setting is performed subsequent to said invoking and wherein said exiting is performed subsequent to said setting.

10. The system of claim 9 , wherein the program instructions further cause the processor to perform:

invoking, by the given thread, an unlock function of the generic concurrency restriction library;

performing, by the given thread, while executing the invoked unlock function:

resetting the lock flag to indicate that the lock is not held; and

invoking an underlying unlock function of the lock, wherein said resetting is performed prior to said invoking.

11. The system of claim 7 , wherein said determining is based, at least in part, on a number of threads currently in the active set.

12. The system of claim 11 , wherein said determining is based, at least in part, on determining whether the number of threads currently in the active set is less than one.

13. A non-transitory, computer-readable storage medium storing program instructions that when executed on one or more computers cause the one or more computers to perform:

beginning execution of a multithreaded application that comprises a plurality of requests to acquire a lock associated with a critical section of code or a shared resource;

invoking, by a given thread of the application, a lock function of a generic concurrency restriction library, wherein the generic concurrency restriction library is configured to manage access to the lock;

determining, by the generic restriction library, whether the given thread should be placed in an active set of threads associated with the lock, wherein threads in the active set are able to contend for the lock;

in response to determining that the given thread should be placed in the active set, the given thread joining the active set of threads and contending for the lock, wherein joining the active set of thread comprises setting a lock flag accessible to other threads of the multithreaded application to indicate that the lock is held;

in response to determining that the given thread should not be placed in the active set, the given thread joining a passive set of threads, wherein threads in the passive set are not able to contend for the lock;

monitoring, by one or more passive threads in the passive set, the lock flag and the number of threads in the active set; and

in response to determining, based on said monitoring, to activate a passive thread, one of the passive threads in the passive set joining the active set.

14. The method of claim 13 , further comprising:

determining, by an active thread in the active set, whether to activate another passive thread in the passive set;

setting, by the active thread in response to determining to activate the other passive thread, an activation signal to indicate that the other passive thread should be activated; and

joining, by the other passive thread in response to the activation signal being set, the active set, wherein after joining the active set the other passive thread is able to contend for the lock.

15. The method of claim 13 , wherein joining the active set of threads comprises:

invoking, by the given thread, an underlying lock function of the lock;

setting a lock flag to indicate that the lock is held, wherein the lock flag is accessible to other threads of the multithreaded application;

exiting the invoked lock function of the generic concurrency restriction library; and

wherein said setting is performed subsequent to said invoking and wherein said exiting is performed subsequent to said setting.

16. The method of claim 15 , further comprising:

invoking, by the given thread, an unlock function of the generic concurrency restriction library;

performing, by the given thread, while executing the invoked unlock function:

resetting the lock flag to indicate that the lock is not held; and

invoking an underlying unlock function of the lock, wherein said resetting is performed prior to said invoking.

17. The method of claim 13 , wherein said determining is based, at least in part, on a number of threads currently in the active set.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Nov 2, 2016
From: DICE, DAVID; KOGAN, ALEX
To: ORACLE INTERNATIONAL CORPORATION
Reel/Frame 040194/0196 →
Continuity (1)
Related Publication 20180107514A1 · Apr 19, 2018
Cited By (1)
US 12,197,947