A common problem of multithreaded applications or separate applications accessing shared memory is concurrency control. Current applications usually use locking to access shared memory, but this has several well-known disadvantages like bad scalability or bad maintainability. As many developers will have experienced, it is an extremely tedious task to choose the right locking granularity (not too many, not too few) and to apply and release them in the right order to avoid deadlocks.
This gets even more critical in multiprocessor environments where locking-based concurrency control can reduce the theoretical performance gain of having multiple processors. On one hand, two threads might for example unnecessarily lock each other out if locks are too coarse-grained even if both threads access different data objects. On the other hand, if locks are too fine grained, the perpetual locking and unlocking operations can cause a lot of unnecessary overhead.
Considering that recent developments in the personal computer area have introduced multicore processors intended for home use, it is extremely important to have efficient and effective concurrency control mechanisms. Developers should thus be able to easily optimize applications in order to explicitly benefit from running on multiple cores.
In the context of a software engineering seminar at my university I wrote a paper about an approach called Software Transactional memory (STM), which enables developers to operate on the memory in a similar way to using database transactions.
Downloads:
0 Responses to “Software Transactional Memory”