Immutable-only value access

[AshleySchaeffer]

Hello, this is definitely related to issue #169 . Sorry to reignite the debate in a new issue, but I'm less precious about the implementation (i.e. it can be part of the entry API). I am seeking a method that returns immutable references to the new value (Ref, not RefMut) after an insert.

As stated in the linked issue, both Entry enum variants use mutable references which, as you likely know, means other threads attempting to access the key must wait until the mutable reference is dropped. In a hot code path this would mean both read and write operations from other threads may cause contention. I believe this works perfectly well for cases where dashmap is the sole provider of shared mutability of values.

However, if the value type of a dashmap handles shared mutability itself, the caller would only need immutable references to it. In essence, I want to rely on dashmap for the coordination of insertion and deletion, but have the freedom to choose how I coordinate mutable access to the value. At present immutable access to a key can not be avoided where the code "gets or inserts" keys.

As a suggestion, could the entry API be duplicated to make entry and entry_mut, where the latter is the current entry API and the former is a duplicate that utilises a EntryRead type that provides only a read guard? The downside is that this would be a breaking change of entry API users, in favour of a more common naming convention. Alternatively, perhaps entry_read could be added leaving the existing entry API as it is today.

Thanks for your time and amazing work <3

[AshleySchaeffer]

I've thought about this further and I don't think it's a correct suggestion based on discussions with others in the community. New key insertion requires dashmap to work out where the key needs to inserted, it's complicated (or at least for my brain). As such I'm closing this issue.

The following offers an optimised read-only path for those using types that implement their own shared mutability controls:

#[derive(Clone)]
struct Bar(Arc<AtomicU8>);

let bar = match dashmap.get(&key) {
    Some(bar_read_guard) => bar_read_guard.value().clone(),
    None => dashmap
        .entry(key)
        .or_insert(Bar::default())
        .value()
        .clone(),
};

Where the key already exists, the read-only path is lock-free.

Where the key does not exist, the first thread to call entry will lock the shard that will be associated with it. This will cause contention for any other thread calling get or entry on a key belonging to the same shard (entry will be called if the thread called get prior to the first thread calling entry). As soon as the value is cloned in either match branch, the lock will be freed, thus contention shouldn't last long.

In the above example, all threads using the same key will get the same Bar. They can then safely mutate the AtomicU8 without locking.

[geekbeast]

I came to a similar conclusion, but really wanted to avoid the extra hashing as my testing using flamegraphs show that is what is consuming the majority of the execution time.

I made a PR(#293) that should address both this and #169