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 Aug 18 2006, 12:39 am
Newsgroups: comp.arch
From: "Chris Thomasson" <cris...@comcast.net>
Date: Thu, 17 Aug 2006 21:39:22 -0700
Local: Fri, Aug 18 2006 12:39 am
Subject: Re: Why no double wide compare and swap on Sparc?
Print | View thread | Show original | Report this message | Find messages by this author
"Joe Seigh" <jseigh...@xemaps.com> wrote in message

news:W7adnZTvqanypxLZnZ2dnUVZ_o-dnZ2d@comcast.com...

> Chris Thomasson wrote:
>> "Joe Seigh" <jseigh...@xemaps.com> wrote
>>>What's with the Sparc architects?

>> IMHO, I believe the major reason 32-bit architectures support DWCAS was
>> to be "64-bit ready"; DWCAS gets converted to normal CAS on 64-bit
>> systems. So, if your 32-bit applications used DWCAS, then they can be run
>> 64-bit arch without changes... Of course there is a caveat...

>> A 32-bit application cannot use DWCAS to manipulate a pointer along with
>> another contiguous variable...

>> struct dosent_work_on_64_bit_s {
>>   void *a;
>>   whatever b;
>> };

>> IMO, the hardware architects' did NOT have lock-free algorithms in mind
>> when they decided to put DWCAS in their 32-bit instruction sets. The fact
>> that 128-bit CAS is not reliably supported seems to support my opinion...

> IBM S370 had double wide compare and swap long before 64 bit support
> became an issue.

Good point. Do you happen to know if they implemented it so they could
successfully pop from a lock-free stack? I wonder....

Humm... Microsoft is using cmpxchg8b for the IBM FreeList algorithm with a
minor tweak... I wonder why cmpxchg16b was added as a processor feature for
x86 64... AFAIK, 64-bit x86 does not reliably support cmpxchg16b.

Also, what the heck was that cmp8xchg16 thing for Itanium all about? Humm...

;)

IIRC, Microsoft has to implement some special modifications to their
implementation in order to get their tweaked version of the IBM FreeList to
run on AMD 64... IIRC, it involves pointer compression to get a 64-bit
pointer and a monotonic version counter (for aba) to fit into a single
CAS... Kind of funny......

>>>There's a bit of a disconnect here I think.

>> Perhaps they are designing the lock-free algorithms for a upcoming
>> processor design. Maybe one that has hardware transactional memory...
>> That could be the reason they designed KCSS:

> They've done a bit on STM (software transactional memory).  If they did
> come out with hardware based transactional memory it would be after the
> fact of 64 bit sparc and wouldn't be generally available.

I wonder why they are messing around with KCSS software emulations that run
very poorly on SPARC64. Actually, they "really" don't need STM or HTM to
implement robust lock-free algorithms' on 64-bit architectures... Not at
all... Seems that they have discovered all of the tricks yet, eh? Perhaps...

> So it would
> have to be hidden behind some system or library api with alternate
> implementations on non TM platforms.  That would limit its applicability.
> For example, you couldn't have atomically thread-safe refcounted smart
> pointers.  Well, not without RCU and/or SMR.  If they go with STM to
> compliment hw TM, it's only going to work at a lower contention level
> if the STM algorihtm is only obstruction-free.

I agree. I also have some problems with obstruction-free algorithms.
Paticuallry, issues that deal with forward progress.

http://groups.google.com/group/comp.arch/msg/9b00fda2752966f9

http://groups.google.com/group/comp.arch/msg/335aeb22fd6fe526

I don't really trust obstruction-free algorithms. They don't seem to like to
deal with a lot of pressure (load)... The forward progress seems to fold
under the contention manager... Once your relying on an explicit contention
manager to give you forward progress, you know you have some problems
somewhere...

> It's a big problem.  You can design efficient synchronization mechanisms
> that are portable if you ignore Sparc.  If you want portability to
> Sparc you have to sacrifice performance or functionality.

Well, after looking at their implementation of a LL/SC emulation... And
reading about how one of their lock-free reference counting has to depend on
it... Makes we want to totally agree with you...

:)

Humm. However, I think have to disagree here Joe... Well, FWIW, I have my
entire vZOOM library running on 64-bit SPARC. it performs equal to or
sometimes better than its 32-bit counterpart. However, unfortunately, you
have go to be very careful when you are designing lock-free algorithms for
SPARC 64; CAS based algorithms that use pointers and a contiguous word will
break...

> If Sun has a 64 bit JVM implementation, I wonder what they do for
> the AtomicMarkedReference and AtomicStampedReference implementations
> for non Sparc platforms.  Cripple them so they perform as poorly as
> the Sparc implementations?

Ditto for AMD64... Yikes!

;)

Humm... It is their fault if they rely on a lock-free algorithm that is not
portable to a 64-bit system. Luckily, for me, converting vZOOM from SPARC 32
to SPARC 64 involved changing ld/sd instructions to ldx/sdx, and cas to
casx. However, there was one thing that pissed be off a bit. I had to give
up my use if the swap instruction. I can't seem to find reference to a swapx
type instruction. I had to hand-craft the 64-bit version of swap with casx,
damn! That turns a call to a simple instruction, swap, into a casx-based
loop.

:O


 
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