[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.


More information about the erlang-questions mailing list