Хэл Фултон - Программирование на языке Ruby

Мы поддерживаем счетчики свободных скрипок и смычков. Когда скрипач хочет получить скрипку и смычок, он должен ждать их освобождения. В программе ниже мы защитили проверку условия мьютексом и под его защитой ждем скрипку и смычок порознь. Если скрипка или смычок заняты, поток засыпает. Он не владеет мьютексом до тех пор, пока другой поток не просигнализирует о том, что ресурс свободен. В этот момент первый поток просыпается и снова захватывает мьютекс.

Код представлен в листинге 13.4.

require 'thread'

@music = Mutex.new

@violin = ConditionVariable.new

@bow = ConditionVariable.new

@violins_free = 2

@bows_free = 1

def musician(n)

loop do

sleep rand(0)

@music.synchronize do

@violin.wait(@music) while @violins_frее == 0

@violins_free -= 1

puts "#{n} владеет скрипкой"

puts "скрипок #@violins_frее, смычков #@bows_free"

@bow.wait(@music) while @bows_free == 0

@bows_free -= 1

puts "#{n} владеет смычком"

puts "скрипок #@violins_free, смычков #@bows_free"

end

sleep rand(0)

puts "#{n}: (...играет...)"

sleep rand(0)

puts "#{n}: Я закончил."

@music.synchronize do

@violins_free += 1

@violin.signal if @violins_free == 1

@bows_free += 1

@bow.signal if @bows_free == 1

end

end

end

threads = []

3.times {|i| threads << Thread.new { musician(i) } }

threads.each {|t| t.join }

Мы полагаем, что это решение никогда не приводит к тупиковой ситуации, хотя доказать этого не сумели. Но интересно отметить, что описанный алгоритм не справедливый. В наших тестах оказалось, что первый скрипач играет чаще двух остальных, а второй чаще третьего. Выяснение причин такого поведения и его исправление мы оставляем читателю в качестве интересного упражнения.

Еще один механизм синхронизации - это монитор, который в Ruby реализован в библиотеке monitor.rb. Это более развитый по сравнению с мьютексом механизм, основное отличие состоит в том, что захваты одного и того же мьютекса не могут быть вложенными, а монитора — могут.

Тривиальный случай возникновения такой ситуации вряд ли возможен. В самом деле, кто станет писать такой код:

@mutex = Mutex.new

@mutex.synchronize do

@mutex.synchronize do

#...

end

end

Но нечто подобное может произойти в сложной программе (или при рекурсивном вызове метода). Какова бы ни была причина, последствием будет тупиковая ситуация. Уход от нее — одно из достоинств модуля-примеси Monitor.

@mutex = Mutex.new

def some_method

@mutex.synchronize do

#...

some_other_method # Тупиковая ситуация!

end

end

def some_other_method

@mutex.synchronize do

#...

end

end

Модуль-примесь Monitorобычно применяется для расширения объекта. Для создания условной переменной предназначен метод new_cond.

Класс ConditionVariableв библиотеке monitor.rbдополнен по сравнению с определением в библиотеке thread. У него есть методы wait_untilи wait_while, которые блокируют поток в ожидании выполнения условия. Кроме того, возможен тайм-аут при ожидании, поскольку у метода waitимеется параметр timeout, равный количеству секунд (по умолчанию nil).

Поскольку примеры работы с потоками у нас кончаются, то в листинге 13.5 мы предлагаем реализацию классов Queueи SizedQueueс помощью монитора. Код приводится с разрешения автора, Шуго Маэда (Shugo Maeda).

# Автор: Shugo Maeda

require 'monitor'

class Queue

def initialize

@que = []

@monitor = Monitor.new

@empty_cond = @monitor.new_cond

end

def enq(obj)

@monitor.synchronize do

@que.push(obj)

@empty_cond.signal

end

end

def deq

@monitor.synchronize do

while @que.empty?

@empty_cond.wait

end

return @que.shift

end

end

end

class SizedQueue < Queue

attr :max

def initialize(max)

super()

@max = max

@full_cond = @monitor.new_cond

end

def enq(obj)

@monitor.synchronize do

while @que.length >= @max

@full_cond.wait

end

super(obj)

end

end

def deq

@monitor.synchronize do

obj = super

if @que.length < @max

@full_cond.signal

end

return obj

end

end

def max=(max)

@monitor.synchronize do