search

efficient / libcuckoo

A high-performance, concurrent hash table
Other
1.62k stars 275 forks source link

Some use cases clarificaitons #44

Closed necromancersecret closed 8 years ago

necromancersecret commented 8 years ago

Hello I am going to use libcuckoo concurrent hash map in my application. Its multi threaded application with thread pool. Few clarificaaitons

  1. Do i need to take care of allocating object before i pass to insert ? I allocate object then I will be taking car of deal locating that too
  2. What's the maximum limit this libcuckoo can support, i mean in terms of no of keys along with its respective object. My object size is around 112 bytes. And ideally at anytime each key will hold just one entry corresponding to its object. During multiple threads execution, if multiple threads are updating the similary key e.g key is 4431 , with different objects? What will happen ?

Neo

necromancersecret commented 8 years ago

Please do share some inputs

manugoyal commented 8 years ago

Hi Neo.

  1. You do not need to take care of allocating memory. Libcuckoo will construct your key and value inside the table and free it when the object is deleted or the table is deleted.
  2. There is not really a maximum size the table can reach. The limiting factor is probably the hash key, which is a size_t. But a size_t usually covers the maximum amount of addressable memory on your machine (usually 64 bits => 2^64 hash table entries), so you shouldn't run into an issue there.
  3. All of the updates will run, but in an unspecified order. So probably the update that runs last will have the winning value.
necromancersecret commented 8 years ago

Thanks Mr. Manugoyal

One more thing. what about the case, If in a multiprocessor machine 2 threads are updating exactly the same key with different objects at exactly the same time , then in that case what will be the results ?

Neo

rob-p commented 8 years ago

Hi Neo,

He already answered this exact question:

All of the updates will run, but in an unspecified order. So probably the update that runs last will have the winning value.

So, in that case, the updates will be linearized. Both will run, but the order is not specified. If your update is something commutative like addition, then the map value will have the sum of the two updates. But, if you're e.g. just setting the key to a certain (possibly different) value from two different threads, then the map will have one or the other of the values. The state will be consistent (I.e. No wrecked memory from concurrent access), but the updates will run in an unspecified order.