RFR: 8185723: Zero: segfaults on Power PC 32-bit

[Andrew Haley]

On 03/08/17 11:43, John Paul Adrian Glaubitz wrote:
> On 08/03/2017 12:06 PM, Andrew Haley wrote:
>> But there may be a better way of handling atomic doublewords on the
>> 68k.  Instead, define an array of lock words and yield on one of them
>> when reading or writing a doubleword.  That way you (probably) only
>> block when two threads really are contending, and the instant you
>> detect contention you yield.

Use lock_address(a) for all atomic double operations.  Then you don't
need any assembly language for 64-bit atomic ops.  It's simple, but
it's not super-efficient.  It has the virtue that it will work on
every platform.

My guess is that it's good enough for Zero.

template <typename T>
static inline int hash(T *a) {
  unsigned int n = (unsigned int)(uintptr_t)a;
  return (n + (n >> 8)) & 255;   // Or simply n % 255 if that's faster
}

template <typename T>
static inline void lock_address(T *a) {
  int n = hash(a);
  while (__sync_lock_test_and_set(&locks[n], 1)) {
    pthread_yield();
  }
}

template <typename T>
static inline void unlock_address(T *a) {
  int n = hash(a);
  __sync_lock_release(&locks[n]);
}

void atomic_copy64(const volatile void *src, volatile void *dst) {
  lock_address(src);
  uint64_t tmp = *(uint64_t*)src;
  unlock_address(src);

  lock_address(dst);
  *(uint64_t*)dst = tmp;
  unlock_address(dst);
}

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671