1. Jan 31, 2020
  2. Jan 30, 2020
  3. Jan 28, 2020
  4. Jan 25, 2020
  5. Jan 24, 2020
  6. Jan 23, 2020
    • Szymon Romik's avatar
      Merge pull request #613 from igchor/stable-1.8-hash_map_erase_fix · 6ab2d17d
      Szymon Romik authored
      Backport hash map erase fix to stable 1.8
      6ab2d17d
    • Igor Chorazewicz's avatar
      d630ba85
    • Igor Chorazewicz's avatar
      concurrent_hash_map: fix possible deadlock in erase · 5b7527b0
      Igor Chorazewicz authored
      Consider the following scenario (where A and B are in the same bucket):
      thread 1:		thread 2:
      find(acc1, A)
      			erase(A)
      find(acc2, B)
      
      First, thread 1 takes lock on the bucket and then on element A.
      Then, thread 2 takes a lock on the bucket and tries to lock element A
      but it can't because thread 1 already locked it - this way thread 2 is blocked.
      Next, thread 1 tries to lock the bucket but it can't because thread 2 holds it.
      Neither thread can progress.
      
      This patch fixes that by introducing the same algorithm as in lookup/insert.
      When trying to lock element in erase we now spin in a loop doing try_acquire and
      if we do not succeed after specified amount of time we drop bucket lock and try
      whole operation again.
      5b7527b0
  7. Jan 14, 2020
  8. Jan 10, 2020
  9. Jan 03, 2020
  10. Dec 31, 2019
  11. Dec 24, 2019
  12. Dec 13, 2019
  13. Dec 12, 2019
  14. Dec 04, 2019
  15. Dec 03, 2019
  16. Dec 02, 2019
  17. Nov 29, 2019
  18. Nov 19, 2019
  19. Nov 14, 2019
  20. Nov 06, 2019
    • Igor Chorazewicz's avatar
      concurrent_hash_map: implement rehash_bucket using a transaction · 88a078cb
      Igor Chorazewicz authored
      This fixes problem with inconsistent state after crash. In previous implementation
      if application crashed in the middle of rehash it was possible that two buckets
      (old and new) pointed to the same element. This meant that size could be too big
      (some elements could be counted twice). Putting all operations which change list
      pointers inside of a transction solves this issue and eliminates requirement
      to have 'restore_after_crash' logic.
      
      set_rehashed is done outside of a transaction because otherwise:
      - on abort rehashed flag would be rolled back by obj using memcpy instead of
        std::atomic API which could be UB
      - some thread could check for rehashed flag and decide that rehash is not needed
        but after that transaction could abort and move elements back
      88a078cb