news:iKudnfC1qrPxZRzenZ2dnUVZ_tGdnZ2d@comcast.com...

Well, Intel's current research seems to be moving toward transactional
memory:

http://www.cambridge.intel-research.net/~rennals/faststm.html

In the near future they may be pushing developers to convert their
applications critical sections into transactions. I believe that they are
going to start to advertise transactional memory as a "general solution"
that can directly address the new multi-core processors that are coming out.
If the do take that path, I am not sure how well its going to work out for
them. They will probably need to put a transactional memory implementation
in the hardware itself. Something like this:

http://ogun.stanford.edu/~kunle/publications/tcc_isca2004.pdf

I am not too sure how well this would scale... It seems as though it could
possibly suffer from livelock-like situations under certain circumstances.
For instance, simple false-sharing may cause some transactions to abort. I
think it would be similar to the live-lock that can occur when there is
false-sharing on a LL/SC based lock-free LIFO anchor and/or nodes;
reservation granularity you know...

Well, the fact that double-width compare-and-swap did not get "reliably"
ported to 64-bit architectures make be think that may be relying on a
magical fairy to come down and show application developers the light...
Luckily there are some algorithms out there (e.g., VZOOM and RCU-SMR) that
can help applications boost performance and efficiently scale-up to the new
multi-core designs right now. However, in order for this stuff to really
take off I believe that its going to take somebody to "bite-the-bullet" and
incorporate one of these solutions into their application architecture. Then
let the performance and scalability improvement(s) speak for themselves...

:)

As of now I am only using VZOOM for in-house projects. Maybe I should do
something commercial with it... Ahhhh, it would probably be a waste of
time... Perhaps I should use it to implement a speedy STM framework, since
transactions seem to be the way things are going to go anyway...

;)