apr
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?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Phoenix, LiveView, multimedia pipelines, distributed systems. 400 engineers, Elixir since 2017. Available for hire.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
OvermindDL1
Worked here on 1.9.2 with erlang 22.22:
apr
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.
garazdawi
It is part of the OTP-16315 optimization where any locks around ETS tables are removed when using only 1 scheduler.
dimitarvp
You mean on single-core systems?
NobbZ
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.
OvermindDL1
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.
apr
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_concurrencytotrue. Why does the optimization still allow for that? Is it because locks for read concurrency are implemented differently?garazdawi
Well, technically the locks in the ETS table still use
read_concurrency, there just aren’t anyIt is just an oversight on my part that it is not removed. I’ll make a note of fixing that in a future release.
apr
Gotcha, thanks for the detailed info