1. 27 Oct, 2016 2 commits
  2. 25 Oct, 2016 2 commits
  3. 24 Oct, 2016 3 commits
  4. 23 Oct, 2016 6 commits
  5. 22 Oct, 2016 3 commits
  6. 21 Oct, 2016 3 commits
  7. 19 Oct, 2016 13 commits
  8. 18 Oct, 2016 5 commits
  9. 17 Oct, 2016 3 commits
    • Sergey Vojtovich's avatar
      MDEV-7148 - Recurring: InnoDB: Failing assertion: !lock->recursive · 8303aded
      Sergey Vojtovich authored
      On PPC64 high-loaded server may crash due to assertion failure in InnoDB
      rwlocks code.
      
      This happened because load order between "recursive" and "writer_thread"
      wasn't properly enforced.
      8303aded
    • Sergey Vojtovich's avatar
      MDEV-10813 - Clean-up InnoDB atomics, memory barriers and mutexes · 2b47f8ff
      Sergey Vojtovich authored
      Clean-up periodic mutex/rwlock waiters wake up. This was a hack needed to
      workaround broken mutexes/rwlocks implementation. We must have sane
      implementations now and don't need these anymore: release thread is
      guaranteed to wake up waiters.
      
      Removed redundant ifdef that has equivalent code in both branches.
      
      Removed os0atomic.h and os0atomic.ic: not used anymore.
      
      Clean-up unused cmake checks.
      2b47f8ff
    • Sergey Vojtovich's avatar
      MDEV-10813 - Clean-up InnoDB atomics, memory barriers and mutexes · 5608a737
      Sergey Vojtovich authored
      No point to issue RELEASE memory barrier in os_thread_create_func(): thread
      creation is full memory barrier.
      
      No point to issue os_wmb in rw_lock_set_waiter_flag() and
      rw_lock_reset_waiter_flag(): this is deadcode and it is unlikely operational
      anyway. If atomic builtins are unavailable - memory barriers are most certainly
      unavailable too.
      
      RELEASE memory barrier is definitely abused in buf_pool_withdraw_blocks(): most
      probably it was supposed to commit volatile variable update, which is not what
      memory barriers actually do. To operate properly it needs corresponding ACQUIRE
      barrier without an associated atomic operation anyway.
      
      ACQUIRE memory barrier is definitely abused in log_write_up_to(): most probably
      it was supposed to synchronize dirty read of log_sys->write_lsn. To operate
      properly it needs corresponding RELEASE barrier without an associated atomic
      operation anyway.
      
      Removed a bunch of ACQUIRE memory barriers from InnoDB rwlocks. They're
      meaningless without corresponding RELEASE memory barriers.
      
      Valid usage example of memory barriers without an associated atomic operation:
      http://en.cppreference.com/w/cpp/atomic/atomic_thread_fence
      5608a737