[erlang-questions] Replacing ets tables - renaming and race condition
Paulo Sérgio Almeida
psa@REDACTED
Wed Apr 4 12:56:53 CEST 2007
Ulf, even if my problem is much simpler than if there were dependencies
between lookups, it is not that simple ...
Namely, your sketched solution still has a race condition.
> Tab = ets:new(tmp, []),
> compute(Tab),
> ets:insert(switch_table, {current, Tab}).
If some process does:
> lookup(Key) ->
> Tab = ets:lookup_element(switch, current, 2),
> ets:lookup(Tab, Key).
it could do the lookup_element, but be interrupted before doing the
lookup. This means the lookup could be to a table that no longer exists
if the recompute is:
> recompute() ->
> Old = ets:lookup_element(switch, current, 2),
> New = ets:new(tmp, []),
> compute(New),
> ets:insert(switch, {current, New}),
> ets:delete(Old).
So, we still have a problem :)
Moreover, this switch table would make usage a bit unpleasant.
To make this thread more interesting, as mnesia/ets is the erlang
"shared memory", I am curious how frequently do people encounter these
kind of race conditions and what (minimal) support there should be
towards enabling fast accesses while ensuring something, like atomicity
(e.g. like update_counter).
What do you think about my "rename with forced atomic delete" proposal.
I think it could have its place.
Regards,
Paulo
More information about the erlang-questions
mailing list