"Joe Seigh" <jseigh...@xemaps.com> wrote in messagenews:hvGdnXAAUoqlaqDYnZ2dnUVZ_rGdnZ2d@comcast.com...
> Nick Maclaren wrote:The cache coherency mechanism that could properly support a robust
>> In article <4q4ledFlff5...@individual.net>,
>> Del Cecchi <cecchinos...@us.ibm.com> writes:
>> |> |> If I interpret this article
>> |> correctly, expecting those stores to not be reordered as seen from |>
>> another cpu is unrealistic unless steps are taken in the software to |>
>> make it so. It is realistic to expect them to occur in order as seen |>
>> from the cpu where they originate.
>> Thanks for finding that; at a quick glance, I agree, and it justifies
> Transactional memory, aka magic at this point.
transactional memory scheme would have to be really strict IMHO... Think of
scenarios in which there could be lots of reader threads iterating over
large shared linked data-structures in parallel... The transactional
coherency system could potentially wind up having to track all of those many
thousands of reads transactions' that will be generated my the frequently
reading threads... It would die from livelock; ahh the explicit contention
manager to the rescue! So, when the times get tough for TM, it basically is
forced to fold under its security blanket, and wait for things to cool way
down for a while... This is because TM is kind of like obstruction free
algorithms... One small trivial interference from another thread, and the
operations dies and asks the contention manager if it can retry...
I don't think TM can scale very well at all wrt the previous scenarios that
Any thoughts on this?
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.