3

Why does the following ruby code not work?

 2 | require 'thread'
 3 | 
 4 | $mutex = Mutex.new
 5 | $mutex.lock
 6 |
 7 | t = Thread.new {
 8 |   sleep 10
 9 |   $mutex.unlock
10 | }
11 | 
12 | $mutex.lock
13 | puts "Delayed hello"

When I'm running it, I get an error:

./test.rb:13:in `lock': thread 0x7f4557856378 tried to join itself (ThreadError)
    from ./test.rb:13

What is the right way to synchronize two threads without joining them (both threads must continue running after synchronization)?

sawa
  • 165,429
  • 45
  • 277
  • 381
Allan
  • 4,562
  • 8
  • 38
  • 59

2 Answers2

10

This is old but I'm contributing since it's a bit scary that none of the other answers (at time of writing) seem to be correct. The original code is clearly attempting to:

  • Create a mutex in the main thread and lock it.
  • Start a new thread, which may begin running at any time and after any delay subject to the whims of the Ruby runtime.
  • Have this thread unlock the mutex only once it's finished doing its work.
  • Have the main thread then deliberately re-lock the mutex, with the intention that it's spawned a thread which will unlock it. The main thread waits for that.
  • Then the main thread continues running.

@user2413915: Your solution omits the step of locking again in the main thread, so it won't wait for the spawned thread as intended.

@Paul Rubel: Your code assumes that the spawned thread gets as far as its lock of the mutex before the main thread does. This is a race condition. If the main thread continues to execute and locks first, the spawned thread will be blocked until after the main thread has printed "Delayed hello", which is the exact opposite of the desired outcome. You probably ran it by pasting into the IRB prompt; if you try with your example modified so that the end and Mutex lock are on the same line, it'll fail, printing the message too early (i.e. "end; $mutex.lock"). Either way, it's relying on behaviour of the Ruby runtime that's working by chance.

The original code should actually work fine in principle, albeit arguably lacking in elegance - in practice the Ruby 1.9+ runtime won't allow it as it "sees" two consecutive locks in the main thread without an unlock and doesn't "realise" that there's a spawned thread which is going to do the unlocking. Ruby (in this case technically erroneously) raises a ThreadError deadlock exception.

Instead, make cunning use of the ruby Queue. When you try to pull something off a Queue, the call will block until an item is available. So:

require 'thread'
require 'queue'

queue = Queue.new

t = Thread.new {
  sleep 10
  queue.push( nil ) # Push any object you like - here, it's a NilClass instance
}

queue.pop() # Blocks until thread 't' pushes onto the queue
puts "Delayed hello"

If the spawned thread runs first and pushes onto the queue, then the main thread will just pop the item and keep going. If the main thread tries to pop before the spawned thread pushes, it'll wait for the spawned thread.

[Edit: Note that the object pushed onto the queue could be the results of the spawned thread's processing task, so the main thread gets to wait until processing is complete and get the processing result in one go].

I've tested this on Ruby 1.8.7-p375 and Ruby 2.1.2 via rbenv with success, so it's reasonable to assume that the standard library Queue class is functional across all common major Ruby versions.

Andrew Hodgkinson
  • 4,379
  • 3
  • 33
  • 43
  • would not be better to just use `Thread#join` ? If I may say, this is an odd requirement from behalf of the OP. Seems that his code needs some refactoring. – yeyo Dec 15 '14 at 04:28
  • I'd say it's reasonable for one thread to let another thread do some processing while it does other things, but later need to wait for the processing thread to complete its task. Queues seem pretty much ideal for that. Perhaps it might be a refactoring task to stop the processing thread from being long-lived and have it transient instead (though this may be inefficient or otherwise inappropriate in context), so that Thread#join would be correct; but as it stands Thread#join is not appropriate, since it requires the processing thread to exit. – Andrew Hodgkinson Dec 15 '14 at 09:50
  • 1
    good catch Andrew. I removed my answer so as not to confuse things. – Paul Rubel Dec 19 '14 at 13:25
-2

You do not need to call the mutex on line 12 again.

require 'thread'

$mutex = Mutex.new
$mutex.lock
t = Thread.new {
  sleep 10
  $mutex.unlock
}

puts "Delayed hello"

This will work.

Luís Cruz
  • 14,780
  • 16
  • 68
  • 100
fvarj
  • 205
  • 1
  • 3
  • 9