ETS set table write concurrency option is not respected

Questions / Help
, ,
1

I am noticing something strange on elixir 1.9.4 with erlang 22.2.

Erlang/OTP 22 [erts-10.6] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]

Interactive Elixir (1.9.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(app@127.0.0.1)1>  :ets.new(:test_table, [:set, :named_table, :public, {:write_concurrency, true}, {:read_concurrency, true}])  
:test_table
iex(app@127.0.0.1)2>  :ets.info(:test_table)
[
  id: #Reference<0.3021804751.1718747137.69759>,
  read_concurrency: true,
  write_concurrency: false,
  compressed: false,
  memory: 301,
  owner: #PID<0.2177.7>,
  heir: :none,
  name: :test_table,
  size: 0,
  node: :"app@127.0.0.1",
  named_table: true,
  type: :set,
  keypos: 1,
  protection: :public
]

It appears that the write_concurrency property is not being respected. Does anybody know if this is a regression?

1 Like
2

Worked here on 1.9.2 with erlang 22.22:

iex(1)> :ets.new(:test_table, [:set, :named_table, :public, {:write_concurrency, true}, {:read_concurrency, true}])  
:test_table
iex(2)> :ets.info(:test_table)
[
  id: #Reference<0.2454829455.2262695941.100902>,
  read_concurrency: true,
  write_concurrency: true,
  compressed: false,
  memory: 1325,
  owner: #PID<0.108.0>,
  heir: :none,
  name: :test_table,
  size: 0,
  node: :nonode@nohost,
  named_table: true,
  type: :set,
  keypos: 1,
  protection: :public
]
3

Very strange. I downloaded Erlang (esl_erlang=1:22.2.1-1) from the erlang-solutions package and the above error showed up. However it works with esl_erlang=1.22.1.8-1. Not sure why it’s working on your Erlang 22.2 and not mine.

4

It is part of the OTP-16315 optimization where any locks around ETS tables are removed when using only 1 scheduler.

13 Likes
5

You mean on single-core systems?

6

No, on systems where only one scheduler is started.

This is the default for single core machines, but you can also do that via runtime flags.

1 Like
7

Ah fascinating, thanks for that! I have 16 schedulers running here so that explains it. Locks are indeed not needed on single-core/single-scheduler systems. :slight_smile:

8

Ah ok, thanks for the info. I did see that in the changelog, but didn’t connect the dots. Also, I am able to set read_concurrency to true. Why does the optimization still allow for that? Is it because locks for read concurrency are implemented differently?

9

Well, technically the locks in the ETS table still use read_concurrency, there just aren’t any :wink:

It is just an oversight on my part that it is not removed. I’ll make a note of fixing that in a future release.

3 Likes
10

Gotcha, thanks for the detailed info :slight_smile: