ConETS table consistency while entries are deleted from 2 processes

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Sun Dec 8 13:56:20 CET 2019


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191208/7332c861/attachment.htm>


More information about the erlang-questions mailing list