Используйте Regexp.new:
if goo =~ Regexp.new(foo) # Evaluates to /0.0.0.0/
Я думаю, вы можете придерживаться java.util.concurrent.LinkedBlockingQueue
независимо от ваших сомнений. Это одновременно. Хотя я понятия не имею о его производительности. Возможно, вам больше подойдет другая реализация BlockingQueue
. Их не так уж много, поэтому проведите тесты производительности и измерьте.
Вы можете попробовать LinkedTransferQueue из jsr166: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/
It соответствует вашим требованиям и снижает накладные расходы на операции предложения / опроса. Как я вижу из кода, когда очередь не пуста, для опроса элементов используются атомарные операции. А когда очередь пуста, она какое-то время вращается и в случае неудачи останавливает поток. Думаю, это может помочь в вашем случае.
Я использую ArrayBlockingQueue всякий раз, когда мне нужно передать данные из одного потока в другой. Использование методов put и take (которые будут блокироваться, если они заполнены / пусты).
Я предлагаю вам взглянуть на ThreadPoolExecutor newSingleThreadExecutor. Он позаботится о том, чтобы ваши задачи были упорядочены за вас, и если вы отправите Callables своему исполнителю, вы также сможете получить желаемое поведение блокировки.
Вот список классов, реализующих BlockingQueue
.
Я бы порекомендовал проверить SynchronousQueue
.
Как @Rorick упомянутый в его комментарии, я считаю, что все эти реализации являются параллельными. Я думаю, что ваши опасения по поводу LinkedBlockingQueue
могут быть неуместными.