Article Categories
- All Categories
-
Data Structure
-
Networking
-
RDBMS
-
Operating System
-
Java
-
MS Excel
-
iOS
-
HTML
-
CSS
-
Android
-
Python
-
C Programming
-
C++
-
C#
-
MongoDB
-
MySQL
-
Javascript
-
PHP
-
Economics & Finance
Transactional memory
Transactional memory originated in database theory and provides an alternative strategy for process synchronization. It allows multiple operations on shared data to be grouped together and executed atomically, without the complexity of traditional locking mechanisms.
A memory transaction is an atomic sequence of memory read-write operations. If all operations in a transaction complete successfully, the transaction is committed. Otherwise, the operations must be aborted and rolled back to maintain data consistency.
Traditional Locking vs Transactional Memory
Consider a function update() that modifies shared data. Traditionally, this function would use mutex locks or semaphores:
void update() {
acquire();
/* modify shared data */
release();
}
However, traditional synchronization mechanisms involve potential problems including deadlock and poor scalability. As the number of threads increases, contention for lock ownership becomes very high.
Using transactional memory, we can add the construct atomic{S} to ensure operations in S execute as a transaction:
void update() {
atomic {
/* modify shared data */
}
}
Advantages of Transactional Memory
No deadlock − Since no locks are involved, deadlock situations cannot occur.
System-managed atomicity − The transactional memory system, not the developer, guarantees atomicity.
Automatic concurrency detection − The system identifies which statements can execute concurrently, such as concurrent read access to shared variables.
Better scalability − Reduces contention compared to traditional locking as thread count increases.
Types of Transactional Memory
Software Transactional Memory (STM)
STM implements transactional memory exclusively in software with no special hardware requirements. It works by inserting instrumentation code inside transaction blocks. A compiler manages each transaction by examining where statements may run concurrently and where specific low-level locking is required.
Hardware Transactional Memory (HTM)
HTM uses hardware cache hierarchies and cache coherency protocols to manage and resolve conflicts involving shared data residing in separate processors' caches. It requires no special code instrumentation and has less overhead than STM. However, it requires modifications to existing cache hierarchies and cache coherency protocols.
Comparison
| Aspect | Traditional Locking | Transactional Memory |
|---|---|---|
| Deadlock Risk | High (possible) | None |
| Scalability | Poor with many threads | Better scalability |
| Programming Complexity | High (manual lock management) | Lower (automatic atomicity) |
| Concurrency Detection | Manual (programmer responsibility) | Automatic (system managed) |
Current Status
Transactional memory has existed for several years without widespread implementation. However, the growth of multicore systems and emphasis on concurrent and parallel programming have prompted significant research in this area from both academics and commercial software and hardware vendors.
Conclusion
Transactional memory offers a promising alternative to traditional locking mechanisms by providing automatic atomicity and eliminating deadlock risks. While both STM and HTM approaches have their trade-offs, transactional memory represents an important step toward simpler and more scalable concurrent programming.
