Prevent segmentation fault in sync and future caches, and also upgrade crossbeam-epoch to v0.9.9

[tatsuya6502]

(Rewritten on July 19, 2022)

Changes

Prevent segmentation fault (use-after-free) in sync and future caches. (Fixes #34):

• It was caused by race-conditions when many threads are concurrently rehashing (extending or shrinking) an internal hash table moka::cht:
  • Although the creator of the original cht designed the rehashing to work fine in such situation, it is not working as expected.
  • To fix it, add a lock to the rehash function to ensure only one thread can participate rehashing at a time.
• To prevent potential inconsistency issues in non x86 based systems, strengthen the memory ordering used for compare_exchange_weak.
  • Before: Ordering::Release, meaning read: relaxed, write: release.
  • After: Ordering::AcqRel, meaning read: acquire, write: release.

Upgrade crossbeam-epoch from v0.8.2 to v0.9.9:

• Upgrade crossbeam-epoch dependency in Cargo.toml from v0.8.2 to v0.9.9.
• Replace deprecated compare_and_set_weak with compare_exchange_weak.

Testing

Ran mokabench with the following arguments several times and no segmentation fault occurred.

$ cargo run --release -- --insert-once --repeat 20

Notes:

• For testing purpose, Modified Moka's code to reduce the number of internal segments of cht from 64 to 1.
  • This will make segfault to occur more often. e.g., without the fix, it occurred within 30 seconds on the Linux x86_64 environment below.
  • The above test took about 30 minutes on the same Linux x86_64 environment, and it no longer occurred after the fix.

Testing environment:

• Linux x86_64 (WSL 2) on Intel Core i7-12700F CPU (20 logical cores)
• macOS arm64 on Apple M1 chip (8 cores)

[tatsuya6502]

I added commit fc044d6, and it should solve #34 (segmentation faults).

To reflect the commit, I rewrote the summary and description of this PR.

[tatsuya6502]

Merging.