wvwwvwwv / scalable-concurrent-containers

High performance containers and utilities for concurrent and asynchronous programming
Apache License 2.0
268 stars 13 forks source link

request: insert_multiple #149

Open tomDev5 opened 3 days ago

tomDev5 commented 3 days ago

I would like to have the ability to insert multiple items at the same time, something like:

///  hash_table.rs
pub fn insert_multiple(&self, items: &[(K, V)]) -> Result<(), &[(K, V)]> {
    todo!()
}

Either insert all elements or insert none of them, with the same lockless action.

changgyoopark-db commented 3 days ago

Hi!

All or nothing! Great idea! The problem is, it will be awfully difficult to implement... I'll think about it. -> If items: [(K, V)] then it will be easier, but still difficult.

tomDev5 commented 3 days ago

You're right, it probably has to be [(K, V)]. Wouldn't it be enough to call hash_table::insert_entry multiple times with the same guard? and if one fails remove all previous items? Or maybe just reserve and insert if everything is successfull, but still.

changgyoopark-db commented 3 days ago

If that's the intended semantics, you can just implement a helper method outside this crate :-) -> In this case, rolling back the operation may not be possible, because other threads will be able to modify any inserted entries.

I thought of something different guaranteeing atomic visibility; until all the keys are inserted, no other threads won't have access to any of them. -> In order to do so, firstly all the buckets have to be locked before inserting any entries (reservation phase), and then entries will be inserted (insertion phase); on uniqueness violation, or an OOM -> rollback everything.

The problem is, locking order is super important to avoid deadlock - firstly, need to calculate hash values of the keys, and sort the keys in accordance with their respective hash values -> not so easy to implement obviously.

tomDev5 commented 3 days ago

Yes, the atomicity is what I had in mind. Understood the complexity, thanks!