有没有合理的理由说Thread.exclusive没有采用"范围"争论?

时间:2012-05-11 17:21:58

标签: ruby multithreading thread-safety

如果要锁定实例上的方法,则必须为每个实例和方法创建Mutex

class Foo
  def initialize
    @blue_mutex = Mutex.new
    @red_mutex = Mutex.new
  end

  def blue
    @blue || @blue_mutex.synchronize do
      @blue ||= Blue.new
    end
  end

  def red_mutex
    @red || @red_mutex.synchronize do
      @red ||= Red.new
    end
  end
end

Thread.exclusive接受参数是否存在逻辑错误?

class Foo
  def blue
    @blue || Thread.exclusive("#{object_id}/blue") do
      @blue ||= Blue.new
    end
  end

  def red
    @red || Thread.exclusive("#{object_id}/red") do
      @red ||= Red.new
    end
  end
end

如果Thread.exclusive只能采用定义排他性范围的参数,为什么要创建互斥锁?

1 个答案:

答案 0 :(得分:0)

简短的回答是API可以按照您描述的方式完成。事实上,这是Java通过让你锁定任意对象所做的事情。它必须发挥技巧,因为跟踪锁会占用对象本身的一些保留空间。此外,当对象被锁定并变得竞争时,必须创建一个真正的互斥体,它使用更多的空间。但希望您的代码不会被锁定和解锁的对象所困扰。我的猜测是,Ruby创建者不希望用这种只会偶尔使用的额外功能来加重每个对象的负担。

我在上面假设当你说“笨拙”时你指的是代码的可读性。如果你担心表现,我怀疑有很大差异。在封面下,任何一种方法都可以使用相同,非常有效的技术。这只是在每个对象上存储细锁的额外内存的问题。我找到了一些关于here

的有趣细节