Deadlock in Concurrent::Array's on non-MRI
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
Start with the linked gist and the Concurrent::Array documentation, then reproduce the behavior on MRI, JRuby, Rubinius, and TruffleRuby. Compare block-taking methods on Concurrent::Array and Concurrent::Hash; done requires a maintainer decision on intended locking semantics and whether behavior should be consistent across implementations.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
concurrent-rubyversion: 1.0.4concurrent-ruby-extinstalled: noconcurrent-ruby-edgeused: no
Take the following code: https://gist.github.com/eregon/323890bfff539f8a33f66d8b2f02cc99
Of course, its purpose is to create a deadlock but it means any method taking a block on Array can cause a deadlock as long as:
- 2+ threads use 2+
Concurrent::Arrayby calling a method taking a block - inside the blocks, the threads call any method taking on another
Concurrent::Array
This seems not such a rare scenario, as it is frequent to call methods in a block that do not only involve the current Array.
The deadlock does not happen on MRI, as it uses a single global lock and concurrent-ruby just subclasses ::Array. It does happen on all other implementations though, like JRuby, Rubinius and TruffleRuby.
The documentation says:
A thread-safe subclass of Array.
This version locks against the object itself for every method call,
ensuring only one thread can be reading or writing at a time.
This includes iteration methods like #each.
So indeed this might imply the deadlock above, but it's not clear.
ensuring only one thread can be reading or writing at a time is also inaccurate on MRI for methods taking a block, as they release the GIL and might switch to another Thread in the middle of e.g. #each.
The same apply for Hash.
Is this behavior intended? Should this be fixed?
Should it behave the same on the different implementations?
- Ngôn ngữ chính
- Ruby
- Star
- 5.8k
- Fork
- 420
- Merge trung bình
- 20 giờ 45 phút
- Pull request đã merge (30 ngày)
- 4
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ruby-concurrency/concurrent-ruby
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
ruby-concurrency/concurrent-ruby#1118 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
ruby-concurrency/concurrent-ruby#1099 · 9 bình luận ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
ruby-concurrency/concurrent-ruby#1095 · 8 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
ruby-concurrency/concurrent-ruby#1093 · 3 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
ruby-concurrency/concurrent-ruby#1091 ·
Tất cả issue của ruby-concurrency/concurrent-ruby
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
バグ
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
-
Version bump for OpenVox 9 Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
voxpupuli/puppet-epel#186 · 1 bình luận ·
-
external_created_at is no longer used for the message timestamp since the new message UI (v4.4.0) Đang mởBug Frontend
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100