OberonCore
https://forum.oberoncore.ru/

Атомарность AWAIT
https://forum.oberoncore.ru/viewtopic.php?f=22&t=93
Страница 1 из 1

Автор:  captain cobalt [ Вторник, 10 Январь, 2006 16:30 ]
Заголовок сообщения:  Атомарность AWAIT

В языке Active Oberon имеется оператор AWAIT, который проверяет условие, и если оно ложно, блокирует процесс до тех пор, пока условие не станет истинным.

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

Каким образом обеспечивается эта атомарность? ;)

Автор:  Alexander Shiryaev [ Вторник, 10 Январь, 2006 17:03 ]
Заголовок сообщения: 

Как я понял, надо чтобы AWAIT находился внутри блока {EXCLUSIVE}

Автор:  Сергей Губанов [ Вторник, 10 Январь, 2006 17:20 ]
Заголовок сообщения:  Re: Атомарность AWAIT

captain cobalt писал(а):
Каким образом обеспечивается эта атомарность? ;)


Атомарность не вообще для всего компьютера, а как эксклюзивный доступ к данному конкретному объекту в методе которого вызван AWAIT. Обеспечивается она в Aos BlueBottle самой средой времени исполнения. Можно эмулировать мониторами.
Код:
PROCEDURE DoSmth;
BEGIN {EXCLUSIVE}
  AWAIT(condition);
  ...
END DoSmth;

Если Вы знакомы с C#, то вот аналог с использованием Монитора:
Код:
void DoSmth ()
{
  System.Threading.Monitor.Enter(this);
  while ( ! condition) System.Threading.Monitor.Wait(this);
  ...
  System.Threading.Monitor.PulseAll(this);
  System.Threading.Monitor.Exit(this);
}

или, с использованием синтаксического сахара lock, так:
Код:
void DoSmth ()
{
  lock (this)
  {
    while ( ! condition) System.Threading.Monitor.Wait(this);
    ...
    System.Threading.Monitor.PulseAll(this);
  }
}

Автор:  captain cobalt [ Вторник, 10 Январь, 2006 18:11 ]
Заголовок сообщения:  Нет, не так

Вопрос в том, как обеспечивается атомарность оператора AWAIT (не компьютера и не объекта), то есть следующих двух действий: проверка условия, блокировка на ложном условии. ;)

Автор:  Сергей Губанов [ Среда, 11 Январь, 2006 10:39 ]
Заголовок сообщения:  Re: Нет, не так

captain cobalt писал(а):
Вопрос в том, как обеспечивается атомарность оператора AWAIT (не компьютера и не объекта), то есть следующих двух действий: проверка условия, блокировка на ложном условии. ;)


В разных операционных системах по разному.

1) Как это делается в Aos BlueBottle написано там:
The Active Object System - Design and Multiprocessor Implementation
http://bluebottle.ethz.ch/docu/technical.html

2) Как это эмулируется с помощью мониторов, я описал в предыдущем сообщении.

3) Как это эмулируется в POSIX описал Владимир Лось:
http://qnxclub.net/modules.php?name=Con ... page&pid=5

Автор:  captain cobalt [ Среда, 11 Январь, 2006 12:38 ]
Заголовок сообщения: 

Первый вариант. ;)

Берём диссер Мюллера:
Цитата:
5.11.1 Await Statement
In Active Oberon, an AWAIT(b) statement, where b is an arbitrary boolean expression, is compiled into a helper procedure and an Await system call.

The helper procedure is equivalent to the following procedure, where the parameter specifies the frame pointer of the procedure containing the await statement and all references to local variables and object fields in the expression b are addressed relative to this parameter. A new name is generated for every helper procedure compiled and it can only be called by the runtime system.
Код:
PROCEDURE $Condition(fp: ADDRESS): BOOLEAN;
BEGIN
   RETURN ”boolean expression from AWAIT statement”
END $Condition;
At the location of the await statement, the equivalent of the following code is compiled to perform the Await system call. The helper procedure ($Condition) and the current frame pointer (FP) are passed to the runtime system so that it can later re-evaluate the condition [31]. The self reference to the associated object instance is also passed as parameter.
Код:
IF NOT $Condition(FP) THEN
   Await($Condition, FP, SELF)
END
The generation of the inline IF statement by the compiler is an optimization. Measurements made while the system was hosting its own development on a dual-processor machine have shown that this avoids on average 70-85% of Await system calls. As a further optimization, the compiler could inline the condition in the IF statement, saving a procedure call at the cost of slightly more object code.
Атомарность последнего оператора IF и вызывает сомнения. ;)

Автор:  Сергей Губанов [ Среда, 11 Январь, 2006 14:59 ]
Заголовок сообщения: 

captain cobalt писал(а):
Атомарность последнего оператора IF и вызывает сомнения.


Всё что находится внутри блока BEGIN {EXCLUSIVE} ... END и есть атомарная операция над объектом. Хоть тысячу IF-ов там разместите, хоть миллион. Атомарность означает, что другая активность не будет впущена ни в один из эксклюзивных блоков кода данного объекта до тех пор пока уже впущенная активность не выйдет из эксклюзивного блока либо не уйдёт в спячку по AWAIT.

Автор:  Trurl [ Среда, 11 Январь, 2006 17:09 ]
Заголовок сообщения: 

Цитата:
Атомарность последнего оператора IF и вызывает сомнения.

А она там и не нужна. Если условие не выпоняется, то Await не будет вызван, а иначе он проверит условие еще раз.

Автор:  captain cobalt [ Среда, 11 Январь, 2006 17:44 ]
Заголовок сообщения: 

А если код, изменяющий истинность условия, не находится внутри EXCLUSIVE-блока? ;)

Автор:  captain cobalt [ Среда, 11 Январь, 2006 18:09 ]
Заголовок сообщения: 

Trurl писал(а):
проверит условие еще раз
Это ещё зачем? Если он всегда вызывается на ложном условии?

Автор:  Сергей Оборотов [ Среда, 11 Январь, 2006 21:08 ]
Заголовок сообщения: 

Сергей Губанов писал(а):
captain cobalt писал(а):
Атомарность последнего оператора IF и вызывает сомнения.


Всё что находится внутри блока BEGIN {EXCLUSIVE} ... END и есть атомарная операция над объектом... Атомарность означает, что другая активность не будет впущена ни в один из эксклюзивных блоков кода данного объекта до тех пор пока уже впущенная активность не выйдет из эксклюзивного блока либо не уйдёт в спячку по AWAIT.
Атомарность, вообще говоря - это неделимость. Если один процесс обращается к данным другого непосредственно - то нельзя говорить о процессе как некоем единстве.

Автор:  Сергей Губанов [ Среда, 11 Январь, 2006 22:56 ]
Заголовок сообщения: 

captain cobalt писал(а):
А если код, изменяющий истинность условия, не находится внутри EXCLUSIVE-блока? ;)

GUEST писал(а):
...Если один процесс обращается к данным другого непосредственно...


Программист должен понимать что он пишет. Всё что изменяет истинность условия обязательно должно быть внутри EXCLUSIVE-блоков. Иначе... - сам дурак! С тем же успехом можно делить на ноль, переполнять буфер, разыменовывать нулевой указатель и т.д. и т.п.

Автор:  Wlad [ Воскресенье, 28 Май, 2006 22:47 ]
Заголовок сообщения: 

captain cobalt писал(а):
А если код, изменяющий истинность условия, не находится внутри EXCLUSIVE-блока? ;)

... Тогда коды, находящиеся в других AWAIT-ах в EXCLUSIVE-блоках данного объекта никогда не узнают, что условие изменилось...
Эта фича АО - реализация Хоаровско-Хансеновских мониторов. Хансен постулировал перепроверку всех мест, где ожидают выполнение истинности неких условий (имеется ввиду "места" в EXCLUSIVE-блоках данного "монитора") на выходе из EXCLUSIVE-блоков.
Соответсвенно, что бы инициировать процесс такой проверки, вы сами должны решить, что будет проверяться, а что нет, помещая или нет некие операции в EXCLUSIVE-блоки или нет...

Автор:  captain cobalt [ Понедельник, 29 Май, 2006 09:59 ]
Заголовок сообщения: 

Здесь можно рассмотреть два случая:
(1) код, который делает условие истинным
(2) код, который делает условие ложным

Если (1) не находится в EXCLUSIVE-блоке, то AWAIT не увидит его работы. Возможно, это иногда имеет смысл.

Если же (2) не находится в EXCLUSIVE-блоке, то AWAIT может разблокироваться на ложном условии. Имеет ли это смысл?

Автор:  Wlad [ Понедельник, 29 Май, 2006 13:16 ]
Заголовок сообщения: 

[quote="captain cobalt"]Здесь можно рассмотреть два случая:
(1) код, который делает условие истинным
(2) код, который делает условие ложным

Если (1) не находится в EXCLUSIVE-блоке, то AWAIT не увидит его работы. Возможно, это иногда имеет смысл.

Если же (2) не находится в EXCLUSIVE-блоке, то AWAIT может разблокироваться на ложном условии. Имеет ли это смысл?[/quote]

"Абажьите!"
При чём здесь сам факт истинности/ложности условия? Нам важен фактор момента "вычисления" условия. Сам случай расположения ХОТЯ БЫ ОДНОГО выражения, влияющего на истинность/ложность выражений, расположенных в AWAIT-ах (данного экземпляра), ВНЕ исключительного блока, является грубейшей ошибкой.
Капитан, это просто такое правило: все потоки, "застывшие" на ложных результатах проверок в AWAIT-ах, перезапускаются для проверки этих же условий в тот момент, когда активный поток покидает EXCLUSIVE-блок в каком-либо методе соответствующего экземпляра.
Будет ли результатом неких операций ВНЕ исключительного блокаи стинность или ложность, для "застывших" потоков значения не имеет - у нас не будет возможности "передёрнуть затвор"...

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/