Is :ets.update_counter efficient?

ETS has many kinds of locks, read and write locks, table and row locks so you don’t necessarily lock the whole table for updates. You can tweak how the locks are used with the read_concurrency and write_concurrency options when you create the table [1]. This is fairly recent paper on the implementation of ETS [2] if you want to learn more.

[1] ets — OTP 29.0.2 (stdlib 8.0.1)
[2] http://winsh.me/papers/erlang_workshop_2013.pdf

Atomic increment means that it’s not possible for anything else to happen during the operation (hence the “atomic” moniker). It does NOT mean it locks the entire ETS table. It means that nothing even has a chance of doing anything to the table while the increment is happening. A lock-free guaranteed atomic operation.

You might also want to look at Erlang’s :atomics module if you need such a functionality.

Thanks for pointing this out. We will update that part of the documentation in OTP 21.3. See Clarify the atomic guarantees for ets:update_counter().

If you are looking for efficient counters, the counters module was introduced in OTP 21.2. I recently used the counters module to speed up cover.

Thanks for the clarifications and the initiative. I really appreciate the effort !

Interesting that this is actually faster than :ets.update_counter and that it is also atomic.
Do the changes in the counter have isolation? From the description:

A is done sequencially before write operation B, then a concurrent reader may see none of them, only A, or both A and B.

I understand that a client can see 2 writes happening at the same time. Or perhaps my definition is atomic operations is not the one shared by the community:

an updating operation to a single object either succeeds or fails completely

Where isolation for me, is the guarantee no that clients cannot see intermediary sates.

As I recall, the :counters module is built on the :atomic module, which is restricted to only word-sized integers or so, and thus it uses hardware-level atomic instructions (CAS and so forth) to perform efficient updates, where :ets’s is more generically typed, unbounded integers, etc… etc…