Erlang / Erlang Advanced Interview questions
What do the write_concurrency and read_concurrency ETS options optimize for?
By default, an ETS table uses a locking scheme tuned for a single, simple access pattern. The
write_concurrency and read_concurrency options let you tell the table engine what
kind of concurrent access to expect, so it can pick internal locking granularity accordingly.
ets:new(my_table, [set, public, {read_concurrency, true}, {write_concurrency, true}]).
- read_concurrency — optimizes for many processes reading concurrently, at a small cost to single-reader latency and to switching between heavy reads and heavy writes.
- write_concurrency — splits the table's internal locks more finely so concurrent writers to different keys don't contend with each other, at the cost of slightly higher memory overhead.
Neither option is free: enabling both gives the best concurrent throughput for a table hit hard from many directions at once, but for a table with light or single-process access, the extra locking machinery is pure overhead with no benefit.
What does enabling write_concurrency change about an ETS table's internal locking?
When are read_concurrency/write_concurrency likely to add unnecessary overhead?
More Related questions...
