ETS table with only counters

[Fred Hebert]

One trick with counters that you update from an ETS table is that you gotta
specify the operation, and the function returns the result. As such, you
can do a write of +0 to the counter and effectively read the value while
using only concurrent write locks. This avoids doing useless switching
between lock types and lets you use the full concurrency mechanisms without
a problem.

On Wed, Nov 25, 2020 at 1:31 PM Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

> A write is when you are changing a value in the table. A read is when you
> are not changing a value in the table. Update counter will change a value
> in the table, potentially, so it'll need a write lock rather than a read
> lock. Since you typically cannot upgrade a lock in the middle from read to
> write, you can assume it needs the write lock. If you never call stuff such
> as lookup, match_object, select, match, ... you are always writing,
> especially if you only call those when you are pulling out stats and such.
> In that case, going for a write_concurrency mode might be beneficial.
>
> On Wed, Nov 25, 2020 at 6:24 PM Frank Muller <frank.muller.erl@REDACTED>
> wrote:
>
>> Hi Jesper,
>>
>> To make it in my mind, my ETS table contains only counters. Following you
>> explanation, you consider a table:
>>
>> 1. write heavy if it mainly uses this kind of updates:
>> ets:update_counter(Tab, Counter, {2, N, 0, 0}).
>>
>> and i should set it to {write_concurrency, true}
>>
>> 2. read heavy if it mainly uses:
>> ets:update_counter(Tab, Counter, {2, 0}).
>>
>> and i should set it to {read_concurrency, true}
>>
>> 3. both read/write heavy if:
>> ets:update_counter(Tab, Counter, [ {2, 0}, {2, N, 0, 0} ]).
>>
>> and i should set it to {read_concurrency, true}, {write_concurrency, true}
>>
>> Am i right?
>>
>> /Frank
>>
>>
>> Wed 25 nov. 2020 à 12:31, Frank Muller <frank.muller.erl@REDACTED>
>> wrote :
>>
>>> Thanks a lot Jesper!
>>>
>>> I thought about using the new counter module, by I don’t know how many
>>> counters I will have in my system. They are created dynamically
>>>
>>> /Frank
>>>
>>> wed 25 nov. 2020 à 11:33, Jesper Louis Andersen <
>>> jesper.louis.andersen@REDACTED> wrote :
>>>
>>>> On Tue, Nov 24, 2020 at 8:33 PM Frank Muller <
>>>> frank.muller.erl@REDACTED> wrote:
>>>>
>>>>> Question: how should i set my table?
>>>>> 1. both concurrency set to true:
>>>>> 2. only read concurrency set to true:
>>>>> 3. only write concurrency set to true:
>>>>>
>>>>> Please explain why?
>>>>>
>>>>>
>>>> 4. Use the 'counters' module.
>>>>
>>>> The caveat is that your counter set is of fixed arity and you have a
>>>> way to look up an index. If both are true, they are likely to beat ETS in a
>>>> measurement benchmark shootout because less locks will be taken on them.
>>>> I'd measure your results.
>>>>
>>>> The answer depends on your read/write patterns for solutions 1-3. And
>>>> the CPU architecture setup, mostly in core count. It's very likely you
>>>> don't get a full answer by thinking about how the locking structures are
>>>> built in isolation. General rules of thumb: If mostly read, go with 2. If
>>>> mostly written, go with 3. If you flip i.e., have a short window in which
>>>> you mostly write and then mostly read for a while, then another
>>>> write-block, ..., then go with 1.
>>>>
>>>> --
>>>> J.
>>>>
>>>
>
> --
> J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201125/628dd7d3/attachment-0001.htm>