System and method for transactional locking using reader-lists
In traditional transactional locking systems, such as Transactional Locking with Read-Write locks (TLRW), threads may frequently update lock metadata, causing system performance degradation. A system and method for implementing transactional locking using reader-lists (TLRL) may associate a respective reader-list with each stripe of data in a shared memory system. Before reading a given stripe as part of a transaction, a thread may add itself to the stripe's reader-list, if the thread is not already on the reader-list. A thread may leave itself on a reader-list after finishing the transaction. Before a thread modifies a stripe, the modifying thread may acquire a write-lock for the stripe. The writer thread may indicate to each reader thread on the stripe's reader-list that if the reader thread is executing a transaction, the reader thread should abort. The indication may include setting an invalidation flag for the reader. The writer thread may clear the reader-list of a stripe it modified.
1. A computer-implemented method, comprising:
a thread executing a transaction in a multi-threaded, transactional memory system, wherein said executing the transaction comprises:
the thread determining whether it is eligible to read a stripe in memory based, at least in part, on a value in a reader-list associated with the stripe;
the thread adding itself to the reader-list if the thread determines that it is not eligible to read a stripe; and
the thread reading the stripe from memory.
2. The method of claim 1 , further comprising, subsequent to said reading the stripe:
a second thread acquiring a write-lock associated with the stripe;
the second thread determining that the thread should be invalidated;
the second thread providing an indication to the thread that the second thread has acquired a write-lock on the stripe; and
the second thread modifying a value of the stripe;
wherein said determining that the thread should be invalidated comprises determining that the thread is on the reader-list associated with the stripe.
3. The method of claim 2 , further comprising:
in response to the thread receiving the indication, the thread aborting the transaction.
4. The method of claim 2 , further comprising:
the second thread removing the thread from the reader-list.
5. The method of claim 2 , wherein said determining that the thread should be invalidated further comprises:
determining that the thread has read the stripe in a transaction and that the thread has not committed the transaction in which the stripe was read.
6. The method of claim 1 , further comprising, subsequent to said reading the stripe:
a second thread acquiring a write-lock associated with the stripe;
the second thread determining that the thread is on the reader-list associated with the stripe;
the second thread determining that the thread is in a commit phase of a transactional execution;
in response to said determining that the thread is in a commit phase, the second thread delaying until the thread exits the commit phase; and
the second thread modifying a value of the stripe.
7. A non-transitory computer-readable storage medium storing program instructions executable by a processor in a multi-threaded, transactional memory system to implement:
a thread executing a transaction, wherein said executing the transaction comprises:
the thread determining whether it is on a reader-list associated with a stripe in memory;
the thread adding itself to the reader-list if the thread determines that it is not on the reader-list; and
the thread reading the stripe from memory.
8. The storage medium of claim 7 , wherein the program instructions are further executable to implement, subsequent to said reading the stripe:
a second thread acquiring a write-lock associated with the stripe;
the second thread determining that the thread should be invalidated;
the second thread providing an indication to the thread that the second thread has acquired a write-lock on the stripe; and
the second thread modifying a value of the stripe;
wherein said determining that the thread should be invalidated comprises determining that the thread is on the reader-list associated with the stripe.
9. The storage medium of claim 8 , wherein the program instructions are further executable to implement:
in response to the thread receiving the indication, the thread aborting the transaction.
10. The storage medium of claim 8 , wherein the program instructions are further executable to implement:
the second thread removing the thread from the reader-list.
11. The storage medium of claim 8 , wherein said determining that the thread should be invalidated further comprises:
determining that the thread has read the stripe in a transaction and that the thread has not committed the transaction in which the stripe was read.
12. The storage medium of claim 7 , wherein the program instructions are further executable to implement, subsequent to said reading the stripe:
a second thread acquiring a write-lock associated with the stripe;
the second thread determining that the thread is on the reader-list associated with the stripe;
the second thread determining that the thread is in a commit phase of a transactional execution;
in response to said determining that the thread is in a commit phase, the second thread delaying until the thread exits the commit phase; and
the second thread modifying a value of the stripe.
13. A system comprising:
one or more processors;
a memory coupled to the one or more processors and storing program instructions executable by the one or more processors to implement:
a thread executing a transaction in a multi-threaded, transactional memory system, wherein said executing the transaction comprises:
the thread determining whether it is on a reader-list associated with a stripe in memory;
the thread adding itself to the reader-list if the thread determines that it is not on the reader-list; and
the thread reading the stripe from memory.
14. The system of claim 13 , wherein the program instructions are further executable to implement, subsequent to said reading the stripe:
a second thread acquiring a write-lock associated with the stripe;
the second thread determining that the thread should be invalidated;
the second thread providing an indication to the thread that the second thread has acquired a write-lock on the stripe; and
the second thread modifying a value of the stripe;
wherein said determining that the thread should be invalidated comprises determining that the thread is on the reader-list associated with the stripe.
15. The system of claim 14 , wherein the program instructions are further executable to implement:
in response to the thread receiving the indication, the thread aborting the transaction.
16. The system of claim 14 , wherein the program instructions are further executable to implement:
the second thread removing the thread from the reader-list.
17. The system of claim 14 , wherein said determining that the thread should be invalidated further comprises:
determining that the thread has read the stripe in a transaction and that the thread has not committed the transaction in which the stripe was read.
18. The system of claim 13 , wherein the program instructions are further executable to implement, subsequent to said reading the stripe:
a second thread acquiring a write-lock associated with the stripe;
the second thread determining that the thread is on the reader-list associated with the stripe;
the second thread determining that the thread is in a commit phase of a transactional execution;
in response to said determining that the thread is in a commit phase, the second thread delaying until the thread exits the commit phase; and
the second thread modifying a value of the stripe.