Subj : Re: transactional memory question To : comp.arch,comp.programming.threads From : Chris Thomasson Date : Tue Oct 04 2005 11:47 am "David Hopwood" wrote in message news:GKx0f.63086$iW5.32264@fe3.news.blueyonder.co.uk... > Chris Thomasson wrote: >>>But does anyone here know any architecture already supporting TM? >> >> IMHO, I believe its too early in the game for actual hardware support, >> even >> though they really do need it in order for TM to become really useful. >> All >> of the software emulations I have seen are loaded with expensive atomic >> operations; mutexs seem more efficient... > > Humm... I do agree that the forward-progress/throughput of "obstruction-free" based data-structures "can be" a bit unstable under load: http://groups.google.com/group/comp.programming.threads/msg/3a5504c314834d86?hl=en http://groups.google.com/group/comp.programming.threads/msg/2218db929b4d5630 ;) As for the presented implementation, it seems to definitely be an improvement over "obstruction-freedom" based designs. However, I do have a little problem with some of the overhead involved. AFAICT, it seems to require readers to keep in sync with the "transaction descriptor", and the proxy collector structures. I really have to study their implementation some more, but is does seem that some memory barriers would be required to sync with the commit operation, and the proxy garbage collector "scanning logic" the code happens to use. off-topic: AFAICT, the proxy gc algorithm doesn't allow for references to exist outside of a "critical-region", just like RCU, so you are going to basically have to invoke it for every access to a transaction and/or shared object if you want the collector to be able to handle any kind of "load"; it looks like it executes a StoreLoad style memory barrier when you enter and leave a GC region, and I think the algorithm has to observe three GC epochs before it can dump its lists... .