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

[Ulf Wiger (TN/EAB)]

What you're saying is basically that the purging
problem exists even for your program...
Why, of course, and this is the eternal crux
with trying to find a low-cost shared-memory
solution to race conditions. (:

The easiest way to solve the race condition is 
to serialize access via a process. You could
also use global:trans(), which more or less
amounts to the same thing.

Perhaps a less destructive BIF would be:

ets:switch_names(Named_table1, Named_table2).

This way, one could easily flip between an
'inactive' and 'active' table, without having
to forcibly destroy data just to do the switch.

Presumably, the function would exit with badarg
if either table is not a named_table.

This would be in line with Erlang's telecom 
tradition, since active/passive tables are 
a common way to deal with subscriber lookup.
Operators enjoy maintaining a passive table 
of subscriber data, and then issue an 'activate'
command, flipping the status of the passive 
table to active, and vice versa.

BR,
Ulf W

> -----Original Message-----
> From: erlang-questions-bounces@REDACTED 
> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of 
> Paulo Sérgio Almeida
> Sent: den 4 april 2007 12:57
> To: Ulf Wiger
> Cc: erlang-questions@REDACTED
> Subject: Re: [erlang-questions] Replacing ets tables - 
> renaming and race condition
> 
> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>