2008-11-18 5 views
2

P1 и P2 - это процессы или узлы в кластере. f1 и f2 - их флаги. Предположим, что модель сильной памяти и что оба процесса могут быть перезапущены в любой момент, и что перезапуск процесса очищает его флаг, вот алгоритм, который я придумал и еще не смог сломать, но это беспокоит меня, потому что это не теоретически доказано и выглядит слишком просто по сравнению с Петерсоном., пожалуйста, нарушите этот алгоритм синхронизации.

P1 start: 
set f1 
if f2 set then clear f1, wait some, goto start 
else enter critical section 
do whatever 
clear f1 

P2 start: 
set f2 
if f1 set then clear f2, wait some, goto start 
else enter critical section 
do whatever 
clear f2 

Может ли кто-нибудь увидеть поток? Кроме того, может быть, что один из процессов может голодать другому, быстро перейдя в раздел?

ответ

5

Если операция «if X set then clear Y» не является атомарной, существует потенциальное состояние гонки, которое может помешать либо войти в критический раздел. Я попытался обрисовать поток ниже:

P1: set f1 
P2: set f2 
P1: is f2 set? 
P2: is f1 set? 
P1: yes, clear f1 
P2: yes, clear f2 
P1: start wait 
P2: start wait 
P1: end wait 
P2: end wait 
P1: goto start 
P2: goto start 

Это потенциально может продолжаться вечно, пока существует разница в распределении делается с помощью планировщика задач, или время ожидания для двух P отличаются друг от друга ,

+0

да, но не совсем: 1) «wait some» означает ожидание разных периодов, например, Ethernet. Просто не написал это явно 2) Я думаю, это не зависит от того, если-ясное не атомарное –

+0

1) Не может решить проблему, в зависимости от того, как вы знаете, как долго ждать. Проверьте возможные столкновения. 2) Если он является атомарным, то по крайней мере один из них сможет войти в критический раздел (тот, который проверяет последний). Голод может произойти, но вы уже это знали, поэтому я не упомянул об этом. –

+0

правда. Для тайм-аутов я буду подражать тому, что делает Ethernet –

0

Ну, кроме голодания, я не вижу никаких других проблем.

Алгоритм Петерсона, однако, гарантирует справедливость - каждый процесс гарантированно получит критический раздел, как только он будет доступен в будущем, - который ваш алгоритм не предоставляет.

Мне любопытно, почему вы считаете, что алгоритм Петерсона менее прост; это не так уж и отличается от того, что у вас есть.

P1 start: 
set f1 
x = 2 
while f2 and (x == 2) wait 
enter critical section, etc. 
clear f1 
+0

Для использования Peterson требуется общая переменная «поворот». В моем случае это два узла в кластере, а общие переменные немного сложнее, чем между потоками. –

+0

Да, но у вас есть две общие переменные: f1 и f2. Петерсону требуется еще одно (все еще булевое в случае двух узлов). Это большая проблема? – Sunlight

0

Легко доказать, что этот алгоритм гарантирует взаимное исключение. Если оба процесса находятся в критической секции одновременно, это означает, что оба флажка установлены, а F1 был установлен до F2 (из кода P1), а также F2 был установлен до F1 (из кода P2). Это невозможно, поэтому взаимное исключение гарантировано.

Это проще, чем у Петерсона, потому что это не гарантирует ограниченного ожидания - сценарий из другого ответа может повторяться бесконечно много раз, хотя с вероятностью быстро сходится к нулю (при условии хорошей случайности периодов ожидания).

+0

да, это только то, что 1) тупики сложнее анализировать и 2) после того, как я увидел перерыв Петерсона на слабой модели памяти, я не доверяю легко :) –

+0

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

+0

он по-прежнему работает даже с общим, но требует использования барьеров памяти. Все еще намного быстрее, чем lock() и контекстные переключатели, но невозможно проверить их достоверно.В моем случае это больше между узлами, чем процессами на узле –

Смежные вопросы