[erlang-questions] Is ets:insert/2 (with multiple objects) isolated with respect to concurrent readers?

Sverker Eriksson sverker@REDACTED
Thu Jul 2 12:21:29 CEST 2009

Chris Newcombe wrote:
> I just noticed that the new {write_concurrency, true} option says that
> write-locks might no-longer be taken at the table level.
>     "Different parts of the same table can be mutated (and read) by
> concurrent processes."
> (full text below)
> It does not say which write/read APIs are allowed to be concurrent.
The idea with write_concurrency was that it should be pure performance 
and not change any guarentees about API semantics.

> So there's the usual natural tension between clean API semantics for
> compound write operations, and increased concurrency.  e.g. Some
> applications might want atomicity, but might care more about increased
> concurrency than full isolation.  Other applications (like my current
> one) might really need strong isolation.
> But I guess that backwards-compatibility reasons will dominate your
> decision (quite understandably).  Given the historic implicit behavior
> (strong isolation) for delete_all_objects, insert, and insert_new, it
> would be dangerous to change them now.   Also, strong isolation
> follows the principle of least surprise.
True, backward-compatibility was the main reason for deciding now about 
the atomic and isolated semantics of insert, insert_new and 
to be guaranteed in the docs.
The introduction of write_concurrency was however about 
with respect only to performance and not semantics.

> It would be great if the updated documentation for the APIs
> specifically described the isolation semantics when
> {write_concurrency,true} is used.
> And vice-versa too; e.g. it would good if the documentation for
> write_concurrency mentioned that compound-write operations will either
> acquire multiple fine-grain write-locks (i.e. acquire all necessary
> locks before modifying anything), or may choose to acquire a
> table-level lock, to ensure (in either case) that their historic
> isolation behavior is preserved.
> Therefore applications that make heavy use of compound-write
> operations might see less benefit from {write_concurrency, true}.
Don't you think it's enough if stated about {write_concurrency,bool()} 
that is does
not break any semantic promises about atomicy and isolation. Maybe note 
that operations
that makes such promises will gain less (or nothing) from 
I don't think we should need to describe the current internal locking 

Also, any guarantees about atomicy and isolation only applies to the data
that the function is operating on.

/Sverker, Erlang/OTP

More information about the erlang-questions mailing list