Seguridad de subprocesos: Variables de clase en Ruby

Question

Realizar escrituras/lecturas en variables de clase en Ruby no es seguro para subprocesos. La realización de escrituras/lecturas en variables de instancia parece ser segura para subprocesos. Dicho esto, ¿es seguro realizar lecturas/lecturas en variables de instancia de una clase o un objeto de metaclase?

¿Cuáles son las diferencias entre estos tres ejemplos (artificiales) en términos de seguridad de subprocesos?

Ejemplo 1:exclusión mutua

class BestUser # (singleton class) 
    @@instance_lock = Mutex.new 

    # Memoize instance 
    def self.instance 
    @@instance_lock.synchronize do 
     @@instance ||= best 
    end 
    end 
end 

Ejemplo 2:almacenamiento de instancia VARIABLE

class BestUser # (singleton class) 
    # Memoize instance 
    def self.instance 
    @instance ||= best 
    end 
end 

Ejemplo 3:almacenamiento de instancia VARIABLE EN MetaClass

class BestUser # (singleton class) 
    # Memoize instance 
    class << self 
    def instance 
     @instance ||= best 
    end 
    end 
end 

Answer 1

Ejemplos 2 y 3 son exactamente lo mismo. Los módulos y las clases también son objetos, y la definición de un método singleton en un objeto realmente lo define en su clase singleton.

Dicho esto, y como ya ha establecido que el acceso variable de la instancia es seguro para la ejecución de subprocesos, los ejemplos 2 y 3 son seguros para la ejecución de subprocesos. El ejemplo 1 también debe ser seguro para subprocesos, pero es inferior a los otros dos porque requiere sincronización de variable manual.

Sin embargo, si necesita aprovechar el hecho de que las variables de clase se comparten en el árbol de herencia, es posible que deba usar el primer enfoque.

---

La seguridad del hilo inherente del lenguaje Ruby depende de la implementación.

MRI, antes 1.9, hilos implementados at the VM level. Esto significa que, aunque Ruby es capaz de programar la ejecución del código, en realidad nada se está ejecutando en paralelo dentro de un único proceso de Ruby. Ruby 1.9 usa subprocesos nativos sincronizados con un global interpreter lock. Solo el contexto que contiene el bloqueo puede ejecutar el código.

n, x = 10, 0 

n.times do 
    Thread.new do 
    n.times do 
     x += 1 
    end 
    end 
end 

sleep 1 
puts x 
# 100 

El valor de x es siempre consistente en la RM. En JRuby, sin embargo, la imagen cambia. Las ejecuciones múltiples del mismo algoritmo arrojaron los valores 76, 87, 98, 88, 94. El resultado podría ser cualquier cosa porque JRuby usa hilos de Java, que son hilos reales y se ejecutan en paralelo.

Al igual que en el lenguaje Java, se requiere sincronización manual para utilizar hilos de manera segura en JRuby. El siguiente código siempre resulta en valores coherentes para x:

require 'thread' 
n, x, mutex = 10, 0, Mutex.new 

n.times do 
    Thread.new do 
    n.times do 
     mutex.synchronize do 
     x += 1 
     end 
    end 
    end 
end 

sleep 1 
puts x 
# 100 

Answer 2

los Ejemplos 2 y 3 son exactamente lo mismo. No son en absoluto hilos de seguridad.

Consulte el ejemplo a continuación.

class Foo 
    def self.bar 
    @bar ||= create_no 
    end 

    def self.create_no 
    no = rand(10000) 
    sleep 1 
    no 
    end 
end 

10.times.map do 
    Thread.new do 
    puts "bar is #{Foo.bar}" 
    end 
end.each(&:join) 

Su resultado no es el mismo. El resultado es el mismo cuando se utiliza mutex como a continuación.

class Foo 
    @mutex = Mutex.new 

    def self.bar 
    @mutex.synchronize { 
     @bar ||= create_no 
    } 
    end 

    def self.create_no 
    no = rand(10000) 
    sleep 1 
    no 
    end 
end 

10.times.map do 
    Thread.new do 
    puts "bar is #{Foo.bar}" 
    end 
end.each(&:join) 

Se ejecuta en CRuby 2.3.0.

Answer 3

Instance variables are not thread safe (y variables de clase son incluso menos seguro de rosca)

Ejemplo 2 y 3, tanto con las variables de instancia, son equivalentes, y son NO hilo seguro, como @VincentXie declaró. Sin embargo, aquí es un mejor ejemplo para demostrar por qué no son:

class Foo 
    def self.bar(message) 
    @bar ||= message 
    end 
end 

t1 = Thread.new do 
    puts "bar is #{Foo.bar('thread1')}" 
end 

t2 = Thread.new do 
    puts "bar is #{Foo.bar('thread2')}" 
end 

sleep 2 

t1.join 
t2.join 

=> bar is thread1 
=> bar is thread1 

Debido a que la variable de instancia es compartida entre todos los hilos, como @VincentXie declaró en su comentario.

PS: Las variables de instancia se refieren a veces como "variables de instancia de clase", dependiendo del contexto en el que se utilizan:

Cuando el yo es una clase, que son variables de instancia de clases (clase variables de instancia). Cuando self es un objeto, son instancias variables de objetos (variables de instancia). - WindorC's answer to a question about this