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
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 revert? How can I possibly reproduce them so I can get
this
On Mar 21, 2013, at 1:54 PM, jplev...@apache.org wrote:
> Updated Branches:
> refs/heads/master 1a2ebccb1 -> f41323e01
>
>
> Fix bug with 128 bit compare and swap.
Hmm, this doesn't build with clang ... it makes clang generate a call to a
___sync_fetch_and_add_1 stub that doesn't exist:
Unde
well done, John.
should we also changed ink_queue_load_64 to
void
ink_queue_load_64(void *dst, void *src)
{
#if (defined(__i386__) || defined(__arm__)) && (SIZEOF_VOIDP == 4)
__sync_fetch_and_add((int64_t*)&(src), 0)
#else
*(void**)dst = *(void**)src;
#endif
}
If not, could you please explai
