Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.arch
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Why no double wide compare and swap on Sparc?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Chris Thomasson  
View profile  
 More options Jun 14 2006, 6:21 pm
Newsgroups: comp.arch
From: "Chris Thomasson" <cris...@comcast.net>
Date: Wed, 14 Jun 2006 15:21:01 -0700
Local: Wed, Jun 14 2006 6:21 pm
Subject: Re: Why no double wide compare and swap on Sparc?
Print | View thread | Show original | Report this message | Find messages by this author
"Andy Glew" <first.l...@employer.domain> wrote in message

news:peyp8xnzl9g2.fsf@PXPL8591.amr.corp.intel.com...

>> > Are there a rule of thumb as to when LL/SC starts showing
>> > scalability issues?

>> IMHO there is no rule of thumb. Scalability issues are not typically
>> induced by LL/SC itself.

> I disagree.

> Although maybe it's not really scalability issues.  LL/SC starts
> introducing deadlock / forward progress issues the moment you have
> more than one processor on any interconnect that is not a simple
> snoopy bus, and they just get worse as you add more, and have more
> complicated interconnects.

Something like this?:

http://groups.google.com/group/comp.arch/msg/d40cf092b679169d

Coarse reservation granularity can cause live-lock in LL/SC via. simple
false-sharing. I really do believe that HTM is going to suffer from the same
thing... Multiple processors can live-lock if they keep interfering with the
reservations that track the TM.

Humm... Kind of like the live-lock that is inherent in any obstruction-free
algorithm; they need to use "backoff-and-retry" algorithms to keep up
forward-progress...


 
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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google