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

[Chris Newcombe]

>> As Ulf mentioned; insert, insert_new and delete_all_objects are all both
>> atomic and isolated.
>>
>> I can't see that we ever would want (and dare) to break that.


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.

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.

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}.

thanks,

Chris

    "{write_concurrency,bool()} Performance tuning. Default is false,
which means that the table is optimized towards concurrent read
access. An operation that mutates (writes to) the table will obtain
exclusive access, blocking any concurrent access of the same table
until finished. If set to true, the table is optimized towards
concurrent write access. Different parts of the same table can be
mutated (and read) by concurrent processes. This is achieve to some
degree at the expense of single access and concurrent reader
performance. Table typ ordered_set is not affected by this option in
current implementation."


On Wed, Jul 1, 2009 at 7:12 AM, Chris Newcombe<chris.newcombe@REDACTED> wrote:
>> I will make that guarantee more explicit in the documentation for next
>> release.
>
> Excellent -- thankyou very much!
>
> Chris
>
>
> On Wed, Jul 1, 2009 at 7:02 AM, Sverker
> Eriksson<sverker@REDACTED> wrote:
>> Ulf Wiger wrote:
>>>
>>> Chris Newcombe wrote:
>>>>
>>>> Please could the isolation behavior be officially documented for
>>>> ets:insert, ets:insert_new, and ets:delete_all_objects?
>>>
>>> Granted, you're asking for official documentation, and I
>>> agree that this is important.
>>>
>> As Ulf mentioned; insert, insert_new and delete_all_objects are all both
>> atomic and isolated.
>>
>> I can't see that we ever would want (and dare) to break that.
>> I will make that guarantee more explicit in the documentation for next
>> release.
>>
>> /Sverker, Erlang/OTP
>>
>>
>>
>>
>