Comparative Performance Analysis of Nested and Non-Nested Transactional Variables in Software Transactional Memory

In concurrent programming, Software Transactional Memory (STM) provides an efficient mechanism formanaging shared memory in parallel computations, avoiding common issues like locks and deadlocks. Acrucial aspect of STM systems is the implementation of transactional variables (TVars), whichsignificantly influence concurrency levels, execution time, and memory overhead. Two primaryimplementations of TVars—nested and non-nested—present distinct advantages and trade-offs. This studyevaluates and compares the effects of nested and non-nested TVar implementations on STM performance,focusing on concurrency, execution time, rollback complexity, and memory overhead. Using the Haskellprogramming language with STM libraries under GHC version 8.6.5, both implementations weredeveloped and tested on a system with an Intel Core i5-1035G1 CPU @ 1.20 GHz, 8 GB DDR4 RAM, anda 512 GB Intel 660p NVMe SSD running Windows 11 Pro. Each configuration executed multiple depositand withdrawal operations over ten iterations: the non-nested version processed approximately 20 STMoperations in a total time of 2.0 seconds, while the nested version performed about 50 operations in 4.0seconds due to additional nested balance adjustments. Execution time and memory usage were measuredusing Haskell’s runtime and heap profiling tools (+RTS -p -hy). The results demonstrate that nested TVarsimprove concurrency by localizing conflicts within sub-transactions, achieving an average operationalthroughput approximately 25% higher than the non-nested version (0.08 seconds per operation for nestedvs. 0.10 seconds for non-nested) and consuming about 38% less total heap memory (38,792 bytes vs.63,080 bytes). Non-nested TVars provide simpler implementation with slightly faster individual executionbut less effective conflict resolution under high load. These insights can guide developers in optimizingSTM-based systems by selecting appropriate TVar models based on the concurrency demands andcomplexity of their applications.