Is there a way to update and erase in a thread-safe way?

[vrn-sn]

I'm using immer::map::update(key_type k, Fn && fn) to update the value associated with a particular key. However, depending on the internal logic of the fn lambda, I may need to erase the key-value pair altogether (same as calling immer::map::erase(const K & k)).

Is there a correct way to do this without running into thread-safety issues? I can think of two solutions, but I feel they are both imperfect.

1. Perform the check and call erase inside fn (to be executed while executing update), and assign this result to my map variable. Is it safe to mutate the map while it is calling its own update function? The update function is marked const, so I assume this is not a great solution, but I may be misunderstanding the restrictions here.
2. Execute update, and keep track of the internal state of fn with a captured boolean variable declared in the caller function's scope. Then, after finishing the update, check this boolean variable to decide whether or not to call erase. Although this doesn't mutate the map while updating it, it also seems like it wouldn't be thread-safe since updating and erasing happen separately.

Is there anything like "update_and_erase", or any patterns I can use to achieve this atomic behavior in a thread-safe way?

[arximboldi]

Hi @VarunSaini02!

Here are some conceptual clarifications:

1. The erase and update functions, like every single const method in an Immer container is thread safe. They are "thread safe" also when applied in multiple steps. I wouldn't advise to mutate the map inside the update() function as it can lead to problems, but a multi-step approach should both be safer and easier to understand.

2. The only method that is not thread-safe in an immer::map is assignment, the operator=. This means that you can not, in an unprotected manner, read a variable of type immer::map and the same time write to it in another thread. This means that if you have a variable called my_map that is shared across threads, you can't safely do:

my_map  = ...;

Regardless of what you put in the ..., let it be my_map.update(...) or my_map.erase(...) or anything else.

One solution to the problem highlighted in 2) is to use mutexes to protect accesses to the map. But even better, you can use immer::atom which is created exactly for this use-case. So you can have a variable shared like this:

  auto my_map = immer::atom<immer::map<string, string>>{};

And in one thread read it and in another thread update it like this:

  my_map.update([](auto value) {
      if (auto item_p = item.find(some_item); item_p) {
          if (some_condition(item_p))
              return std::move(value).erase(some_item);
          else
             return std::move(value).set(some_item, transform(*item_p));
      }
      return value;
  });

Everything that you do in the atom::update() method is considered an atomic operation, and everything is safe even if we get there in multiple steps.

Does this make sense?

Btw, I see that you work at @Roblox. That's pretty cool :) Are you using Immer for projects there? I would be interested to learn more about your use-case, please throw a message: [email protected]

[vrn-sn]

Thanks for the clear explanation, that does make sense! I was using immer::atom without realizing it (was under a type alias), so it looks like everything will work as intended for my use case.

They are "thread safe" also when applied in multiple steps.

One clarification—what do you mean by multiple steps in this case? A small example would be helpful, if possible.

[arximboldi]

By multiple steps I mean something where you do multiple operations to the map, like:

auto new_map = some_map .erase("foo").set("bar", 42);
return new_map.update("baz", [](auto x) { return ++x; } );

Even if some_map is shared, and we do multiple operations, this is thread safe because we don't do some_map = ... anywhere in the code.