OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 24 Май, 2024 19:28

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
 Заголовок сообщения: Атомарность AWAIT
СообщениеДобавлено: Вторник, 10 Январь, 2006 16:30 

Зарегистрирован: Воскресенье, 27 Ноябрь, 2005 07:19
Сообщения: 11
Откуда: /ru/perm
В языке Active Oberon имеется оператор AWAIT, который проверяет условие, и если оно ложно, блокирует процесс до тех пор, пока условие не станет истинным.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 10 Январь, 2006 17:03 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 02:12
Сообщения: 473
Откуда: KZ
Как я понял, надо чтобы AWAIT находился внутри блока {EXCLUSIVE}


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Атомарность AWAIT
СообщениеДобавлено: Вторник, 10 Январь, 2006 17:20 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
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);
  }
}


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Нет, не так
СообщениеДобавлено: Вторник, 10 Январь, 2006 18:11 

Зарегистрирован: Воскресенье, 27 Ноябрь, 2005 07:19
Сообщения: 11
Откуда: /ru/perm
Вопрос в том, как обеспечивается атомарность оператора AWAIT (не компьютера и не объекта), то есть следующих двух действий: проверка условия, блокировка на ложном условии. ;)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Нет, не так
СообщениеДобавлено: Среда, 11 Январь, 2006 10:39 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 11 Январь, 2006 12:38 

Зарегистрирован: Воскресенье, 27 Ноябрь, 2005 07:19
Сообщения: 11
Откуда: /ru/perm
Первый вариант. ;)

Берём диссер Мюллера:
Цитата:
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 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
captain cobalt писал(а):
Атомарность последнего оператора IF и вызывает сомнения.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 11 Январь, 2006 17:09 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1429
Цитата:
Атомарность последнего оператора IF и вызывает сомнения.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 11 Январь, 2006 17:44 

Зарегистрирован: Воскресенье, 27 Ноябрь, 2005 07:19
Сообщения: 11
Откуда: /ru/perm
А если код, изменяющий истинность условия, не находится внутри EXCLUSIVE-блока? ;)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 11 Январь, 2006 18:09 

Зарегистрирован: Воскресенье, 27 Ноябрь, 2005 07:19
Сообщения: 11
Откуда: /ru/perm
Trurl писал(а):
проверит условие еще раз
Это ещё зачем? Если он всегда вызывается на ложном условии?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 11 Январь, 2006 21:08 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1030
Сергей Губанов писал(а):
captain cobalt писал(а):
Атомарность последнего оператора IF и вызывает сомнения.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Среда, 11 Январь, 2006 22:56 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
captain cobalt писал(а):
А если код, изменяющий истинность условия, не находится внутри EXCLUSIVE-блока? ;)

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 28 Май, 2006 22:47 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
captain cobalt писал(а):
А если код, изменяющий истинность условия, не находится внутри EXCLUSIVE-блока? ;)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Понедельник, 29 Май, 2006 09:59 

Зарегистрирован: Воскресенье, 27 Ноябрь, 2005 07:19
Сообщения: 11
Откуда: /ru/perm
Здесь можно рассмотреть два случая:
(1) код, который делает условие истинным
(2) код, который делает условие ложным

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Понедельник, 29 Май, 2006 13:16 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1693
[quote="captain cobalt"]Здесь можно рассмотреть два случая:
(1) код, который делает условие истинным
(2) код, который делает условие ложным

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

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB