On Mar 25, 2013, at 12:37 PM, Brian Geffon wrote:
> That's great news. When you commit the change w/ sync_val_compare_and_swap
> will you reenable 128 bit freelist cas in configure.ac?
Done.
>
> Brian
>
> On Mon, Mar 25, 2013 at 12:26 PM, James Peach wrote:
>
>> On Mar 25, 2013, at 11:46 AM
That's great news. When you commit the change w/ sync_val_compare_and_swap
will you reenable 128 bit freelist cas in configure.ac?
Brian
On Mon, Mar 25, 2013 at 12:26 PM, James Peach wrote:
> On Mar 25, 2013, at 11:46 AM, John Plevyak wrote:
>
> > Sure, whatever works. I did a little looking
On Mar 25, 2013, at 11:46 AM, John Plevyak wrote:
> Sure, whatever works. I did a little looking around, but I couldn't find
> any other way to do an atomic read of 128 bits on x86_64.
Yeh, __sync_val_compare_and_swap seems to work ...
>
> john
>
> On Mon, Mar 25, 2013 at 11:44 AM, Brian Gef
Sure, whatever works. I did a little looking around, but I couldn't find
any other way to do an atomic read of 128 bits on x86_64.
john
On Mon, Mar 25, 2013 at 11:44 AM, Brian Geffon wrote:
> It turns out that __sync_fetch_and_add(__int128_t*, int) just uses
> cmpxchg16b under the covers anywa
It turns out that __sync_fetch_and_add(__int128_t*, int) just uses
cmpxchg16b under the covers anyway...
int main ( void ) {
__int128_t src=10, dest=20;
*(__int128_t*)&(dest) = __sync_fetch_and_add((__int128_t*)&src, 0);
return 0;
}
When building using gcc -mcx16 -S -o test.S test.c, we get the
On Mar 24, 2013, at 2:11 PM, Brian Geffon wrote:
> I'm confused, I reenabled 128bit cas in configure.ac and verified that it
> is building with cmpxchg16b and it's running perfectly. The test_freelist
> regression tests pass with no problems. So what were the issues remaining
> that required the
