Question

I use a Concurrency::concurrent_unordered_map successfully in my program (this is an implementation made by Microsoft). This is needed because multiple inserts/updates for elements and quite rare deletes are performed in a concurrent manner.

I know that this container (like all other concurrent containers) provides an unsafe erase() method – for erasing a node.

What would you think would be the best approach to make the erase process also thread safe ? This happens rarely as I’ve said (only because user intervention) and I would not like so much to have a critical section that has to be entered every time I perform a search on the container (or for that matter any other operations like iterator traversal and node updates). What do you think? I was also thinking on an event based mechanism but I don’t see how this is applicable here.

Answer 1

Actually the involvement of a critical section to make the erase process concurrent safe defeats the purpose of using a concurrent container at all in my case. If one would use such an approach every operation that relates to the concurrent container would have to be guarded by the same lock (i.e. operations that until now wouldn’t have had to step on each others toe now have to wait on the same critical section). So this is by far the worst idea that renders your concurrent container useless in every situation that you might use it.

An idea that addresses the mentioned inconveniences would be to use a Reader Writer lock. This allows shared reads but exclusive writes. One should protect the deletes with a writer lock and every other operation on the map with a reader lock like this:

    InsertOperation(key) -- this inserts the key in case is not present (and constructs a default constructed value)
    {
       reader_writer_lock::scoped_lock_read guard(reader_writer_lock);
       ...
    }

    value Find(key)
    {
        reader_writer_lock::scoped_lock_read guard(reader_writer_lock);
        ...
     }

     void EraseElement(key)
     {
        reader_writer_lock::**scoped_lock** guard(reader_writer_lock);
        ...
     }