Ruby gives you two basic ways to organize your program so that you can run different parts of it “at the same time.” You can split up cooperating tasks within the program, using multiple threads, or you can split up tasks between different programs, using multiple processes. Let's look at each in turn.
Often the simplest way to do two things at once is by using Ruby threads. These are totally in-process, implemented within the Ruby interpreter. That makes the Ruby threads completely portable—there is no reliance on the operating system—but you don't get certain benefits from having native threads. You may experience thread starvation (that's where a low-priority thread doesn't get a chance to run). If you manage to get your threads deadlocked, the whole process may grind to a halt. And if some thread happens to make a call to the operating system that takes a long time to complete, all threads will hang until the interpreter gets control back. However, don't let these potential problems put you off—Ruby threads are a lightweight and efficient way to achieve parallelism in your code.
Creating a new thread is pretty straightforward. Here's a simple code fragment that downloads a set of Web pages in parallel. For each request it's given, the code creates a separate thread that handles the HTTP transaction.
require 'net/http'
pages = %w( www.rubycentral.com
www.awl.com
www.pragmaticprogrammer.com
)
threads = []
for page in pages
threads << Thread.new(page) { |myPage|
h = Net::HTTP.new(myPage, 80)
puts "Fetching: #{myPage}"
resp, data = h.get('/', nil )
puts "Got #{myPage}: #{resp.message}"
}
end
threads.each { |aThread| aThread.join }
produces:
Fetching: www.rubycentral.com
Fetching: www.awl.com
Fetching: www.pragmaticprogrammer.com
Got www.rubycentral.com: OK
Got www.pragmaticprogrammer.com: OK
Got www.awl.com: OK
Let's look at this code in more detail, as there are a few subtle things going on.
New threads are created with the Thread.new
call. It is given a block that contains the code to be run in a new thread. In our case, the block uses the net/http
library to fetch the top page from each of our nominated sites. Our tracing clearly shows that these fetches are going on in parallel.
When we create the thread, we pass the required HTML page in as a parameter. This parameter is passed on to the block as myPage. Why do we do this, rather than simply using the value of the variable page within the block?
A thread shares all global, instance, and local variables that are in existence at the time the thread starts. As anyone with a kid brother can tell you, sharing isn't always a good thing. In this case, all three threads would share the variable page. The first thread gets started, and page is set to http://www.rubycentral.com. In the meantime, the loop creating the threads is still running. The second time around, page gets set to http://www.awl.com. If the first thread has not yet finished using the page variable, it will suddenly start using its new value. These bugs are difficult to track down.
However, local variables created within a thread's block are truly local to that thread—each thread will have its own copy of these variables. In our case, the variable myPage will be set at the time the thread is created, and each thread will have its own copy of the page address.
Another subtlety occurs on the last line in the program. Why do we call join
on each of the threads we created?
When a Ruby program terminates, all running threads are killed, regardless of their states. However, you can wait for a particular thread to finish by calling that thread's Thread#join
method. The calling thread will block until the given thread is finished. By calling join
on each of the requestor threads, you can make sure that all three requests have completed before you terminate the main program.
In addition to join
, there are a few other handy routines that are used to manipulate threads. First of all, the current thread is always accessible using Thread.current
. You can obtain a list of all threads using Thread.list
, which returns a list of all Thread
objects that are runnable or stopped. To determine the status of a particular thread, you can use Thread#status
and Thread#alive?
.
Also, you can adjust the priority of a thread using Thread#priority=
. Higher-priority threads will run before lower-priority threads. We'll talk more about thread scheduling, and stopping and starting threads, in just a bit.
As we described in the previous section, a thread can normally access any variables that are in scope when the thread is created. Variables local to the block of a thread are local to the thread, and are not shared.
But what if you need per-thread variables that can be accessed by other threads—including the main thread? Thread
features a special facility that allows thread-local variables to be created and accessed by name. You simply treat the thread object as if it were a Hash
, writing to elements using []=
and reading them back using []
. In this example, each thread records the current value of the variable count in a thread-local variable with the key mycount
. (There's a race condition in this code, but we haven't talked about synchronization yet, so we'll just quietly ignore it for now.)
count = 0
arr = []
10.times do |i|
arr[i] = Thread.new {
sleep(rand(0)/10.0)
Thread.current["mycount"] = count
count += 1
}
end
arr.each {|t| t.join; print t["mycount"], ", " }
puts "count = #{count}"
produces:
8, 0, 3, 7, 2, 1, 6, 5, 4, 9, count = 10
The main thread waits for the subthreads to finish and then prints out the value of count captured by each. Just to make it more interesting, we have each thread wait a random time before recording the value.
What happens if a thread raises an unhandled exception? It depends on the setting of the http://abort_on_exception flag, documented on pages 384 and 387.
If abort_on_exception
is false
, the default condition, an unhandled exception simply kills the current thread—all the rest continue to run. In the following example, thread number 3 blows up and fails to produce any output. However, you can still see the trace from the other threads.
threads = []
6.times { |i|
threads << Thread.new(i) {
raise "Boom!" if i == 3
puts i
}
}
threads.each {|t| t.join }
produces:
0
1
2
45prog.rb:4: Boom! (RuntimeError)
from prog.rb:8:in `join'
from prog.rb:8
from prog.rb:8:in `each'
from prog.rb:8
However, set abort_on_exception to true
, and an unhandled exception kills all running threads. Once thread 3 dies, no more output is produced.
Thread.abort_on_exception = true
threads = []
6.times { |i|
threads << Thread.new(i) {
raise "Boom!" if i == 3
puts i
}
}
threads.each {|t| t.join }
produces:
01
2
prog.rb:5: Boom! (RuntimeError)
from prog.rb:7:in `initialize'
from prog.rb:7:in `new'
from prog.rb:7
from prog.rb:3:in `times'
from prog.rb:3
In a well-designed application, you'll normally just let threads do their thing; building timing dependencies into a multithreaded application is generally considered to be bad form.
However, there are times when you need to control threads. Perhaps the jukebox has a thread that displays a light show. We might need to stop it temporarily when the music stops. You might have two threads in a classic producer-consumer relationship, where the consumer has to pause if the producer gets backlogged.
Class Thread
provides a number of methods to control the thread scheduler. Invoking Thread.stop
stops the current thread, while Thread#run
arranges for a particular thread to be run. Thread.pass
deschedules the current thread, allowing others to run, and Thread#join
and Thread#value
suspend the calling thread until a given thread finishes.
We can demonstrate these features in the following, totally pointless program.
t = Thread.new { sleep .1; Thread.pass; Thread.stop; }
t.status → "sleep"
t.run
t.status → "run"
t.run
t.status → false
However, using these primitives to achieve any kind of real synchronization is, at best, hit or miss; there will always be race conditions waiting to bite you. And when you're working with shared data, race conditions pretty much guarantee long and frustrating debugging sessions. Fortunately, threads have one additional facility—the idea of a critical section. Using this, we can build a number of secure synchronization schemes.
The lowest-level method of blocking other threads from running uses a global “thread critical” condition. When the condition is set to true
(using the Thread.critical=
method), the scheduler will not schedule any existing thread to run. However, this does not block new threads from being created and run. Certain thread operations (such as stopping or killing a thread, sleeping in the current thread, or raising an exception) may cause a thread to be scheduled even when in a critical section.
Using Thread.critical=
directly is certainly possible, but it isn't terribly convenient. Fortunately, Ruby comes packaged with several alternatives. Of these, two of the best, class Mutex
and class ConditionVariable
, are available in the Thread
library module.
Mutex
is a class that implements a simple semaphore lock for mutually exclusive access to some shared resource. That is, only one thread may hold the lock at a given time. Other threads may choose to wait in line for the lock to become available, or may simply choose to get an immediate error indicating that the lock is not available.
A mutex is often used when updates to shared data need to be atomic. Say we need to update two variables as part of a transaction. We can simulate this in a trivial program by incrementing some counters. The updates are supposed to be atomic—the outside world should never see the counters with different values. Without any kind of mutex control, this just doesn't work.
count1 = count2 = 0
difference = 0
counter = Thread.new do
loop do
count1 += 1
count2 += 1
end
end
spy = Thread.new do
loop do
difference += (count1 - count2).abs
end
end
sleep 1
Thread.critical = 1
count1 → 184846
count2 → 184846
difference → 58126
This example shows that the “spy” thread woke up a large number of times and found the values of count1 and count2 inconsistent.
Fortunately we can fix this using a mutex.
require 'thread'
mutex = Mutex.new
count1 = count2 = 0
difference = 0
counter = Thread.new do
loop do
mutex.synchronize do
count1 += 1
count2 += 1
end
end
end
spy = Thread.new do
loop do
mutex.synchronize do
difference += (count1 - count2).abs
end
end
end
sleep 1
mutex.lock
count1 → 21192
count2 → 21192
difference → 0
By placing all accesses to the shared data under control of a mutex, we ensure consistency. Unfortunately, as you can see from the numbers, we also suffer quite a performance penalty.
Using a mutex to protect critical data is sometimes not enough. Suppose you are in a critical section, but you need to wait for some particular resource. If your thread goes to sleep waiting for this resource, it is possible that no other thread will be able to release the resource because it cannot enter the critical section—the original process still has it locked. You need to be able to give up temporarily your exclusive use of the critical region and simultaneously tell people that you're waiting for a resource. When the resource becomes available, you need to be able to grab it and reobtain the lock on the critical region, all in one step.
This is where condition variables come in. A condition variable is simply a semaphore that is associated with a resource and is used within the protection of a particular mutex. When you need a resource that's unavailable, you wait on a condition variable. That action releases the lock on the corresponding mutex. When some other thread signals that the resource is available, the original thread comes off the wait and simultaneously regains the lock on the critical region.
require 'thread'
mutex = Mutex.new
cv = ConditionVariable.new
a = Thread.new {
mutex.synchronize {
puts "A: I have critical section, but will wait for cv"
cv.wait(mutex)
puts "A: I have critical section again! I rule!"
}
}
puts "(Later, back at the ranch...)"
b = Thread.new {
mutex.synchronize {
puts "B: Now I am critical, but am done with cv"
cv.signal
puts "B: I am still critical, finishing up"
}
}
a.join
b.join
produces:
A: I have critical section, but will wait for cv
(Later, back at the ranch...)
B: Now I am critical, but am done with cv
B: I am still critical, finishing up
A: I have critical section again! I rule!
For alternative implementations of synchronization mechanisms, see monitor.rb
and sync.rb
in the lib
subdirectory of the distribution.
Sometimes you may want to split a task into several process-sized chunks—or perhaps you need to run a separate process that was not written in Ruby. Not a problem: Ruby has a number of methods by which you may spawn and manage separate processes.
There are several ways to spawn a separate process; the easiest is to run some command and wait for it to complete. You might find yourself doing this to run some separate command or retrieve data from the host system. Ruby does this for you with the system
and backquote methods.
system("tar xzf test.tgz")
→ tar: test.tgz: Cannot open:
No such file or directory
tar: Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors
false
result = `date`
result → "Sun Jun 9 00:08:50 CDT 2002\n"
The method Kernel::system
executes the given command in a subprocess; it returns true
if the command was found and executed properly, false
otherwise. In case of failure, you'll find the subprocess's exit code in the global variable $?.
One problem with system
is that the command's output will simply go to the same destination as your program's output, which may not be what you want. To capture the standard output of a subprocess, you can use the backquotes, as with `date`
in the previous example. Remember that you may need to use String#chomp
to remove the line-ending characters from the result.
Okay, this is fine for simple cases—we can run some other process and get the return status. But many times we need a bit more control than that. We'd like to carry on a conversation with the subprocess, possibly sending it data and possibly getting some back. The method IO.popen
does just this. The popen
method runs a command as a subprocess and connects that subprocess's standard input and standard output to a Ruby IO
object. Write to the IO
object, and the subprocess can read it on standard input. Whatever the subprocess writes is available in the Ruby program by reading from the IO
object.
For example, on our systems one of the more useful utilities is pig
, a program that reads words from standard input and prints them in pig Latin (or igpay atinlay). We can use this when our Ruby programs need to send us output that our 5-year-olds shouldn't be able to understand.
pig = IO.popen("pig", "w+")
pig.puts "ice cream after they go to bed"
pig.close_write
puts pig.gets
produces:
iceway eamcray afterway eythay ogay otay edbay
This example illustrates both the apparent simplicity and the real-world complexities involved in driving subprocesses through pipes. The code certainly looks simple enough: open the pipe, write a phrase, and read back the response. But it turns out that the pig
program doesn't flush the output it writes. Our original attempt at this example, which had a pig.puts
followed by a pig.gets
, hung forever. The pig
program processed our input, but its response was never written to the pipe. We had to insert the pig.close_write
line. This sends an end-of-file to pig
's standard input, and the output we're looking for gets flushed as pig
terminates.
There's one more twist to popen
. If the command you pass it is a single minus sign (“--”), popen
will fork a new Ruby interpreter. Both this and the original interpreter will continue running by returning from the popen
. The original process will receive an IO
object back, while the child will receive nil
.
pipe = IO.popen("-","w+")
if pipe
pipe.puts "Get a job!"
$stderr.puts "Child says '#{pipe.gets.chomp}'"
else
$stderr.puts "Dad says '#{gets.chomp}'"
puts "OK"
end
produces:
Dad says 'Get a job!'
Child says 'OK'
In addition to popen
, the traditional Unix calls Kernel::fork
, Kernel::exec
, and IO.pipe
are available on platforms that support them. The file-naming convention of many IO
methods and Kernel::open
will also spawn subprocesses if you put a “|
” as the first character of the filename (see the introduction to class IO
for details). Note that you cannot create pipes using File.new
; it's just for files.
Sometimes we don't need to be quite so hands-on: we'd like to give the subprocess its assignment and then go on about our business. Some time later, we'll check in with it to see if it has finished. For instance, we might want to kick off a long-running external sort.
exec("sort testfile > output.txt") if fork == nil
# The sort is now running in a child process
# carry on processing in the main program
# then wait for the sort to finish
Process.wait
The call to Kernel::fork
returns a process id in the parent, and nil
in the child, so the child process will perform the Kernel::exec
call and run sort. Sometime later, we issue a Process::wait
call, which waits for the sort to complete (and returns its process id).
If you'd rather be notified when a child exits (instead of just waiting around), you can set up a signal handler using Kernel::trap
. Here we set up a trap on SIGCLD
, which is the signal sent on “death of child process.”
trap("CLD") {
pid = Process.wait
puts "Child pid #{pid}: terminated"
exit
}
exec("sort testfile > output.txt") if fork == nil
# do other stuff...
produces:
Child pid 31842: terminated
IO.popen
works with a block in pretty much the same way as File.open
does. Pass popen
a command, such as date
, and the block will be passed an IO
object as a parameter.
IO.popen ("date") { |f| puts "Date is #{f.gets}" }
produces:
Date is Sun Jun 9 00:08:50 CDT 2002
The IO
object will be closed automatically when the code block exits, just as it is with File.open
.
If you associate a block with Kernel::fork
, the code in the block will be run in a Ruby subprocess, and the parent will continue after the block.
fork do
puts "In child, pid = #$$"
exit 99
end
pid = Process.wait
puts "Child terminated, pid = #{pid}, exit code = #{$? >> 8}"
produces:
In child, pid = 31849
Child terminated, pid = 31849, exit code = 99
One last thing. Why do we shift the exit code in $? 8 bits to the right before displaying it? This is a “feature” of Posix systems: the bottom 8 bits of an exit code contain the reason the program terminated, while the higher-order 8 bits hold the actual exit code.
Extracted from the book "Programming Ruby - The Pragmatic Programmer's Guide"
Copyright © 2001 by Addison Wesley Longman, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.