ConETS table consistency while entries are deleted from 2 processes

[Jesper Louis Andersen]

I think both would work.

There is also the possibility B sends a delete message to A which then
deletes keys. This forces linearization in A.

How many concurrent deletes you have sort-of determines if this strategy is
more viable, and also in which direction the system might go in the future.
If you only have a handful deletes I would just factor it through a single
process since a lot of things are easier that way, typically.

In any case, your Erlang/OTP version matter here. For 22.0 and onwards, you
can set `{write_concurrency, true}` for ordered_set tables and expect an
improvement as core count increases. Before, there is no effect and you are
essentially grabbing a table lock for the whole table whenever you want to
issue a write (i.e. delete). So before 22, concurrent deletes yields no
performance improvement, which argues a messaging model might be simpler to
reason about[0].

[0] Why? Because there is an invariant which is easy to maintain: if the
process is purging, messages wait in the mailbox. So no other deletes can
happen in between. If the process is deleting, it cannot be purging.



On Sun, Dec 8, 2019 at 3:07 PM Frank Muller <frank.muller.erl@REDACTED>
wrote:

> Crystal clear Jesper, thanks.
>
> is purge1/1 valid/correct?
>
> /Frank
>
> On Sun, Dec 8, 2019 at 9:29 AM Frank Muller <frank.muller.erl@REDACTED>
>> wrote:
>>
>>> Hi all
>>>
>>>
>>> Lets assume a public ETS table of type ‘ordered_set’.
>>>
>>>
>> The ETS documentation defines "safe traversal". Traversal of
>> `ordered_set` tables are always safe. That is, they will do the "right
>> thing" if updates are done while traversal happens.
>>
>> For tables of the other types, you either do the whole traversal in one
>> call, or you use the safe_fixtable/2 call to fix the table while traversal
>> is happening.
>>
>> The underlying reason is that the table has an order. This means we can
>> always drill down into the table and find the place we "were" so to speak
>> by utilizing this order. In the case of e.g., `set` tables, we don't a
>> priori have an order, so we are encoding something like a hash bucket and
>> the element we reached. But if that element is gone, we don't know where we
>> were, and there is no other structural information to go by. The fixtable
>> calls basically postpones changes to the table in a separate buffer until
>> the traversal is done, then replays the buffer on the table. This ensures
>> the core table is traversal-stable. Requests to the table first checks the
>> buffer before checking the main core table[0]
>>
>> [0] This model is essentially a 2 level log-structured-merge-tree (LSM
>> tree) variant.
>>
>> --
>> J.
>>
>

-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191208/d099a400/attachment.htm>