withoutboats / waitmap

123 stars 11 forks source link

contention on hashmap #3

Open withoutboats opened 4 years ago

withoutboats commented 4 years ago

once a value is inserted into the map, all wakers waiting on that value are awoken. If there is more than one waker, this could put contention on that shard of the map, because the implementation of wait gets exclusive access to the entry during polling.

benchmarks would be good to see how much performance degrades when multiple tasks are awaiting the same location in the map, and then we could consider other implementations.

withoutboats commented 4 years ago

The Entry API demonstrates a good example of this problem. Imagine a user has tasks waiting on an entry, and then does this:

let value: RefMut<'_, K, V, S> = map.entry(key).or_insert(value);
// hold and mutate value

Every task waiting on that entry will be awoken and will block until this reference is dropped.

It would be ideal if the underlying map used async-aware RwLocks on the shards so that the waiting futures could yield control instead blocking. Of course this would mean even more slots where we'd need to register wakers.