From b55ba329ba25ba4322efdf16053280a5f7dd1a5d Mon Sep 17 00:00:00 2001 From: Sverker Eriksson Date: Wed, 23 Jan 2013 16:46:08 +0100 Subject: erts,stdlib: Increase number of locks for write_concurrency --- lib/stdlib/doc/src/ets.xml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'lib/stdlib/doc/src') diff --git a/lib/stdlib/doc/src/ets.xml b/lib/stdlib/doc/src/ets.xml index abaf64fb91..44c050a0d3 100644 --- a/lib/stdlib/doc/src/ets.xml +++ b/lib/stdlib/doc/src/ets.xml @@ -932,7 +932,8 @@ ets:select(Table,MatchSpec), If set to true, the table is optimized towards concurrent write access. Different objects of the same table can be mutated (and read) by concurrent processes. This is achieved to some degree - at the expense of sequential access and concurrent reader performance. + at the expense of memory consumption and the performance of + sequential access and concurrent reading. The write_concurrency option can be combined with the read_concurrency option. You typically want to combine these when large concurrent @@ -944,8 +945,11 @@ ets:select(Table,MatchSpec), atomicy and isolation. Functions that makes such promises over several objects (like insert/2) will gain less (or nothing) from this option.

-

Table type ordered_set is not affected by this option in current - implementation.

+

In current implementation, table type ordered_set is not + affected by this option. Also, the memory consumption inflicted by + both write_concurrency and read_concurrency is a + constant overhead per table. This overhead can be especially large + when both options are combined.

-- cgit v1.2.3