ETS table with only counters

[Frank Muller]

Fred, that’s what I’ve shown in point 2 and 3.

/Frank

Wed 25 nov. 2020 à 20:31, Fred Hebert <mononcqc@REDACTED wrote :

> 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/10cdcb39/attachment.htm>