Deadlock in Concurrent::Array's on non-MRI

Aperta
#627 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
ruby
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug looking-for-contributor medium-priority
  • concurrent-ruby version: 1.0.4
  • concurrent-ruby-ext installed: no
  • concurrent-ruby-edge used: 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::Array by 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?

Lingua principale
Ruby
Stelle
5.8k
Fork
420
Merge medio
20h 45m
PR unite (30g)
4

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ruby-concurrency/concurrent-ruby

Tutte le issue di ruby-concurrency/concurrent-ruby

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.