[erlang-questions] Replacing ets tables - renaming and race condition

[Thomas Lindgren]

--- Paulo Sérgio Almeida <psa@REDACTED> wrote:

> 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:
> 
/.../
> 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).

For parallel code using sequences of ets operations,
you run into potential race conditions all the time;
my personal conclusion is that the ets API is
fundamentally broken for this sort of use. I think
this was discussed previously on this list under the
heading "atomic ets" or something like that.

I seem to remember that the conclusion at the time was
that in general the safe approach is to use mnesia
instead. And you can of course sometimes design your
code to avoid the problem altogether. However, as far
as I'm concerned, a better term storage API (that is,
an ets replacement) would definitely be nice.

Best,
Thomas




 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html