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

Чтобы поместить элемент в очередь и извлечь из нее, рекомендуется применять соответственно методы enqи deq. Можно было бы для помещения в очередь пользоваться также методом push, а для извлечения — методами popи shift, но их названия не так мнемоничны в применении к очередям.

Метод empty?проверяет, пуста ли очередь, а метод clearопустошает ее. Метод size(и его синоним length) возвращает число элементов в очереди.

# Предполагается, что другие потоки не мешают...

buff = Queue.new

buff.enq "one"

buff.enq "two"

buff.enq "three"

n1 = buff.size # 3

flag1 = buff.empty? # false

buff.clear

n2 = buff.size # 0

flag2 = buff.empty? # true

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

Необязательный параметр non_blockметода deqв классе Queueпо умолчанию равен false. Если же он равен true, по при попытке извлечь элемент из пустой очереди он не блокирует поток, а возбуждает исключение ThreadError.

Условная переменная — это, по существу, очередь потоков. Они используются в сочетании с мьютексами для лучшего управления синхронизацией потоков.

Условная переменная всегда ассоциируется с каким-то мьютексом. Ее назначение — освободить мьютекс до тех пор, пока не начнет выполняться определенное условие. Представьте себе ситуацию, когда поток захватил мьютекс, но не готов продолжать выполнение. Тогда он может заснуть под контролем условной переменной, ожидая, что будет разбужен, когда условие станет истинным.

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

Рассмотрим несколько искусственный пример в духе задачи об обедающих философах. Представьте себе, что вокруг стола сидят три скрипача, ожидающих своей очереди поиграть. Но у них есть всего две скрипки и один смычок. Понятно, что скрипач сможет играть, только если одновременно завладеет одной из скрипок и смычком.

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

Код представлен в листинге 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