[erlang-questions] Design question -- a valid or foolhardy approach to ets update?

[Ulf Wiger]

Mihai Balea wrote:
>
> Just be aware that atomic updates means that updates will still be 
> serialized - you will still run into a concurrency bottleneck since the 
> operation will prevent any other access to the table while it is in 
> progress. It will probably be faster than the gen_server solution, but 
> still not a fully concurrent approach.

In OTP R13B01, the concurrency granularity of ets table updates
can be tuned.

 From the documentation of ets:new(...):

"{write_concurrency,bool()}
Performance tuning. Default is false, which means that the table is 
optimized towards concurrent read access. An operation that mutates 
(writes to) the table will obtain exclusive access, blocking any 
concurrent access of the same table until finished. If set to true, the 
table is optimized towards concurrent write access. Different parts of 
the same table can be mutated (and read) by concurrent processes. This 
is achieve to some degree at the expense of single access and concurrent 
reader performance. Table typ ordered_set is not affected by this option 
in current implementation."

Note also that update_counter() requires the key to already
exist in the table. Try to find a good place to initially
create the counter. Otherwise, a fairly common pattern is:

update_counter(Key, Incr) ->
    try ets:update_counter(?tab, Key, {#counter.value, Incr})
    catch
       error:_ -> init_counter(Key, Incr)
    end.

init_counter(Key, Incr) ->
    true = ets:insert_new(?tab, #counter{key = Key, value = Incr}),
    Incr.

...but this obviously messes with atomicity.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com