Add SccIndexTable

[wvwwvwwv]

Add scc::HashIndex which is highly optimised for read-heavy workloads.

[arthurprs]

Out of curiosity (I haven't dug in the implementation) does IndexTable not guarantee reads will see a previous write? Asking because I saw Linearizability: HashIndex read operations are not linearizable. in the documentation.

[wvwwvwwv]

@arthurprs That requires some understanding of the computer architecture and memory ordering semantics.

The C++/Rust memory ordering model does not define any kind of data freshness, so for instance,

• initial state: v = 2.
• time X: thread 1 - v.compare_exchange(2, 3, release)
• time X + 1: thread 2 - v.load(acquire)

There is absolutely no guarantee that thread 2 at time X + 1 reads "3" according to the language specs.

However, it is true that most microarchitectures including X86 and AARCH64 guarantee data freshness after an RMW (like CAS) operation which happens in the cache coherency protocol level.

Linearizability: HashIndex read operations are not linearizable. <- it is about the C++/Rust memory ordering model and the HashIndex implementation.
-> Write operations of HashIndex can be epitomised by "thread 1 - v.compare_exchange(2, 3, release)".
-> Lock-free read operations of HashIndex are basically "thread 2 - v.load(acquire)".

This implies that, in theory, readers are not guaranteed to observe the latest state of the HashIndex instance, because the C++/Rust memory model lacks a data freshness guarantee, however in reality, readers observe the latest state of the HashIndex, because the hardware "usually" guarantees it.

In short, HashIndex operations are linearizable on X86 and AARCH64.

[arthurprs]

I'm fairly sure most threaded code in the wild assumes an acquire load will see the outcome of a previous release write. But I see your point that it's not guaranteed all the way.

[wvwwvwwv]

Right, that is a common misbelief; v.load(acquire) is modelled as load -> acquire fence.