Здравствуйте, Mr. None, Вы писали:
MN>Ещё раз определение активного объекта — это объект обладающий собственным потоком управления, в рамках которого будут исполняться все запросы (синхронные или асинхронные) к данному объекту.
Гораздо чаще можно встретить такое определение.
Активный объект — это объект обладающий собственным потоком управления.
Сергей Губанов пишет:
> MN>...Ещё раз определение активного объекта — это объект обладающий > собственным потоком управления, в рамках которого будут исполняться > все запросы (синхронные или асинхронные) к данному объекту... > Да с какой стати все-то? Не все, а некоторые. Есть же целое семейство > запросов не нуждающихся в синхронизации вообще (не имеющих EXCLUSIVE > блока). Например методы навроде: > >int GetValue() >{ > return this.privateValue; >} > > уж точно не нуждаются в синхронизации и могут исполняться > непосредственно в вызывающем потоке параллельно с остальными потоками > не вызывая накладных расходов на блокировку.
Неправда, даже такие методы нуждаются в синхронизации (в 99% случаев),
точнее нужен read-barrier, который создается при синхронизации. Читатать
здесь: http://gee.cs.oswego.edu/dl/cpj/jmm.html , хотя тут и про Java
написано, но принципы остаются теми же самыми.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Privalov, Вы писали:
P>>Потому что в системах типа Windows процесс содержит не менее одного потока. Т>А причем тут "системы типа Windows" ?
Потому что я не знаю точное определение потока в системах типа UNIX, OS/2 или OS/360.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Zonnon активности именно так и устроены: активные объекты могут вести диалог по заранее описанному в EBNF форме протоколу — каждый из них находится в своем потоке, а посланные ему сообщения ставятся в очередь. Только кроме этого, дополнительно, можно исполнять методы объекта как обычно — в потоке вызвавшем этот метод, а когда выполнение дойдет до EXCLUSIVE блока (если дойдет), то тут уже сложно сказать где чей поток, так как внутри EXCLUSIVE блока одновременно может находится только один поток, а какой он — вызвавший, вызываемый или третий специальный... это уже не так важно.
... думаете вы! (с) синхронный перевод с немецкого.
Эксклюзивным может и должен быть доступ к разделяемым данным — например, к активному объекту целиком. А не посещение отдельных участков кода.
Представь себе, что есть две эксклюзивные функции, работающие с разделяемыми данными некоего АО.
Посторонний АО залез в первую (и заблокировал её), ещё один посторонний АО — во вторую (и также заблокировал). А дальше они поплясали вместе на костях.
Ну и кому нафиг это надо?
Ну так не модно. Настоящие пацаны заводят объект-локер.
4) Понятие активного объекта и форма его реализации, введённое в статье известны сто лет. По сути -- запуск потока с передачей управления методу объекта.
Плюс к объекту добавлен объект для синхронизации внутри его методов -- колоссальный прорыв в программировании. Ну а если хочется несколько крит. секций использовать в активном объекте, тогда как?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Mr. None, Вы писали:
MN>>Ещё раз определение активного объекта — это объект обладающий собственным потоком управления, в рамках которого будут исполняться все запросы (синхронные или асинхронные) к данному объекту.
Т>Гораздо чаще можно встретить такое определение. Т>
Активный объект — это объект обладающий собственным потоком управления.
А вот это не совсем корректно. Под этот термин попадает в том числе объектная обёртка, создающий для выполнения некоторой операции поток, а это уже не активный объект..
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Mr. None, Вы писали:
MN>>...согласно банальной культуре оформления статей...
СГ>Так, на всякий случай замечу, что это претензии, вообще-то, к автору статьи, а не ко мне.
MN>> Вот пока не приведёте ссылку, давайте вы не будете переливать из пустого в порожнее.
СГ>Вот активные объекты, не из книжки вычитанные, а уже реализованные настоящие живые: http://bluebottle.ethz.ch/ СГ>А вот, собственно, и сам автор Prof. Dr. Jurg Gutknecht (автор языка Active Oberon, соавтор нескольких ОО операционных систем, руководитель группы Programming Languages and Runtime Systems Research Group в ETH) http://www.inf.ethz.ch/personal/gutknech/ у него на странице есть ссылки на соотвествующую литературу (правда некоторые по немецки).
Я вам про Фому, а вы мне про Ерёму... Что вы мне ссылки кидаете на какие-то непонятные реализации непонятно чего... Тем более, что я там не нашёл ни одного определения активного объекта.
СГ>... а когда выполнение дойдет до EXCLUSIVE блока (если дойдет), то тут уже сложно сказать где чей поток, так как внутри EXCLUSIVE блока одновременно может находится только один поток, а какой он — вызвавший, вызываемый или третий специальный... это уже не так важно.
Ничего не понял, какой EXCLUSIVE блок, откуда столько потоков и почему неважно, какой работает...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Материал подготовлен на основе глав книги Антона Элиенса — "Принципы объектно-ориентированной разработки программ".
Идея активных объектов возникла в результате попыток объекдинения объектно-ориентированной парадигмы и поддержки параллельных вычислений в языках программирования. Активный объект харктеризуется наличием так называемого тела (body) — собственного независимого потока управления объекта в рамках которого может выполняться некоторая функциональность. Это позволяет нескольким активным объектам выполнять свои действия параллельно. Взаимодействие между активным объектами осуществляется с помощью синхронного механизма рандеву. Чтобы включиться в рандеву, активный объект должен явным образом прервать исполнение своего тела с помощью специального оператора приёма, предусмотренного средой исполнения (accept). Вызов этого оператора уведомляет среду исполнения о том, что активный объект желает получить очередное сообщение от другого объекта (активного или нет) и возможно ответить на него. Отправка сообщений активному объекту может быть как синхронной так и асинхронной.
Понятие активного объекта сопряжено с рядом проблем. Основная проблема — возможность само-блокировки активного объекта при попытке отправить сообщения самому себе. Другая чисто философская — если язык программирования поддерживает активные объекты, должны ли все объекты быть активными или наряду с активными объектами возможно наличие пассивных объектов.
В таком виде активные объекты, с точностью до названий терминов и наименований операторов, представлены в следующих языках программирования: POOL [1], Ада, Hybrid [2], sC++ [3] (версия C++, расширенная синхронными активными объектами — язык предложен и описан, но реализован не был). Предлагалась реализация этого понятия в языке Java, но без поддержки на уровне компилятора.
Естественное развитие идея активных объектов получила в языке Distributed Smalltalk [4] (рапределённый Smalltalk). Этот язык поддерживает объекты, которые могут реально располагаться на разных процессорах и даже разных машинах и общаться друг с другом посредством передачи сообщений.
1. America P. [1987] POOL-T: a parallel object-oriented language; in Object-oriented concurent systems [Yonezawa A., Tokoro M., MIT Press 1987].
2. Nierstrasz O. [1987] Active objects in Hybrid; in Proc. OOPSLA'87, pp. 243-253.
3. PetitPierre C. [1998] Synchronous C++, a language for interactive applications, IEEE Computer, 31(9), pp.65-72.
4. Bennett J. K. [1987] The design and implementation of Distributed Smalltalk; in Proc. OOPSLA'87, pp. 318-330.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Mr. None, Вы писали:
MN>>>...согласно банальной культуре оформления статей...
СГ>>Так, на всякий случай замечу, что это претензии, вообще-то, к автору статьи, а не ко мне.
MN>>> Вот пока не приведёте ссылку, давайте вы не будете переливать из пустого в порожнее.
СГ>>Вот активные объекты, не из книжки вычитанные, а уже реализованные настоящие живые: http://bluebottle.ethz.ch/ СГ>>А вот, собственно, и сам автор Prof. Dr. Jurg Gutknecht (автор языка Active Oberon, соавтор нескольких ОО операционных систем, руководитель группы Programming Languages and Runtime Systems Research Group в ETH) http://www.inf.ethz.ch/personal/gutknech/ у него на странице есть ссылки на соотвествующую литературу (правда некоторые по немецки).
MN>Я вам про Фому, а вы мне про Ерёму... Что вы мне ссылки кидаете на какие-то непонятные реализации непонятно чего... Тем более, что я там не нашёл ни одного определения активного объекта.
Не стал всё сваливать в кучу: читать про активный объекты здесь.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, Трурль, Вы писали:
Т>>Здравствуйте, Mr. None, Вы писали:
MN>>>Ещё раз определение активного объекта — это объект обладающий собственным потоком управления, в рамках которого будут исполняться все запросы (синхронные или асинхронные) к данному объекту.
Т>>Гораздо чаще можно встретить такое определение. Т>>
Активный объект — это объект обладающий собственным потоком управления.
MN>А вот это не совсем корректно. Под этот термин попадает в том числе объектная обёртка, создающий для выполнения некоторой операции поток, а это уже не активный объект..
Не стал всё сваливать в кучу: прочитать про активный объекты можно здесь.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Кодт, Вы писали:
К> Эксклюзивным может и должен быть доступ к разделяемым данным — например, к активному объекту целиком. А не посещение отдельных участков кода.
Разумеется так и есть. У одного объекта есть много методов. Внутри каждого метода может быть несколько эксклюзивных секций кода. Внутрь какой либо эксклюзивной секции данного объекта одновременно впускается только одна активность. До тех пор пока эта активность там хозяйничает, никакая другая активность ни в какой другой эксклюзивный блок данного объекта впущена не будет. Таким образом, изменение данных этого объекта одновременно происходит только врамках одного потока, остальные ждут пока он не выйдет из эксклюзивного блока либо не уснет в нем на AWAIT.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Разумеется так и есть. У одного объекта есть много методов. Внутри каждого метода может быть несколько эксклюзивных секций кода. Внутрь какой либо эксклюзивной секции данного объекта одновременно впускается только одна активность. До тех пор пока эта активность там хозяйничает, никакая другая активность ни в какой другой эксклюзивный блок данного объекта впущена не будет. Таким образом, изменение данных этого объекта одновременно происходит только врамках одного потока, остальные ждут пока он не выйдет из эксклюзивного блока либо не уснет в нем на AWAIT.
Вот только это называется не активным объектом, а объектом, использующим потоки и синхронизацию доступа...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Mr. None, Вы писали:
MN>Идея активных объектов возникла в результате попыток объекдинения объектно-ориентированной парадигмы и поддержки параллельных вычислений в языках программирования. Активный объект харктеризуется наличием так называемого тела (body) — собственного независимого потока управления объекта в рамках которого может выполняться некоторая функциональность. Это позволяет нескольким активным объектам выполнять свои действия параллельно.
До этого места замечательно. А дальше почему-то описывается механизм рандеву и утверждается, что именно так и должны взаимодействовать активные объекты.
Задачи Ады, естественно, используют рандеву, но вряд-ли их можно считать объектами. В Hybrid, как правило, несколькр активных объектов разделяют один поток.
Недоумение вызывает и следующее утверждение: MN>... sC++ [3] (версия C++, расширенная синхронными активными объектами — язык предложен и описан, но реализован не был).
The current version of our extensions, containing a preprocessor, a run time library and two libraries that implement UNIX sockets and Motif widgets as active objects, is freely available on the anonymous server
Acive Objects: a Paradigm for Communications and Event Driven Systems, G. Caal, A. Divin, C. Petitpierre,1994
Здравствуйте, Сергей Губанов, Вы писали:
К>> Эксклюзивным может и должен быть доступ к разделяемым данным — например, к активному объекту целиком. А не посещение отдельных участков кода.
СГ>Разумеется так и есть. У одного объекта есть много методов. Внутри каждого метода может быть несколько эксклюзивных секций кода. Внутрь какой либо эксклюзивной секции данного объекта одновременно впускается только одна активность. До тех пор пока эта активность там хозяйничает, никакая другая активность ни в какой другой эксклюзивный блок данного объекта впущена не будет. Таким образом, изменение данных этого объекта одновременно происходит только врамках одного потока, остальные ждут пока он не выйдет из эксклюзивного блока либо не уснет в нем на AWAIT.
Тогда в чём сермяжная правда и отличие от захвата-освобождения мутексов, практикуемого во многих средах и языках?
Для любителей делать begin-end блоки — в С++ предусмотрена идиома scope guard.
Здравствуйте, eao197, Вы писали:
E>Если уж архитектор (проектировщик) не должен думать о том, будет ли приложение работать в виде одного многопоточного процесса или множества однопоточных процессов, то...
А, собственно, что то...?
Если уж архитектор (проектировщик) не должен думать о том, в каком оверлее (вариант: на какой дорожке) должна размещаться процедура то...
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, eao197, Вы писали:
E>>Если уж архитектор (проектировщик) не должен думать о том, будет ли приложение работать в виде одного многопоточного процесса или множества однопоточных процессов, то...
Т>А, собственно, что то...?
А то, что если приложение работает в виде взаимодействующих потоков, то нужно решать, какой механизм взаимодействия между ними нужно использовать: CORBA, PVM, MPI, собственное решение на базе pipe, shared memory, sockets. Должны ли процессы запускаться по одному на каждый запрос (транзакцию) или нужно иметь пул процессов. Должно ли решение использоваться на SMP архитектурах или на sharing nothing класстерах. Такая БД для приложения должна использоваться. И т.д. и т.п.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Кодт, Вы писали:
К>Тогда в чём сермяжная правда и отличие от захвата-освобождения мутексов, практикуемого во многих средах и языках? К>Для любителей делать begin-end блоки — в С++ предусмотрена идиома scope guard.
Серьмяжная правда заключается в повышении уровня абстракции.
На одной чаше весов находятся всего три универсальных понятия "EXCLISIVE, AWAIT, ACTIVE" на другой чаше весов находятся процессы, потоки, мютексы, мониторы, сигналы, этот Ваш scope guard, и т.д. и т.п. Весы находятся в равновесии ибо сущности равновесны. Однако: "EXCLISIVE, AWAIT, ACTIVE" — это понятия уровня проектирования, в то время как "процессы, потоки, мютексы, мониторы, сигналы, и т.д. и т.п." — это понятия низкоуровневой реализации.
Здравствуйте, Cyberax, Вы писали:
C>Функциональные языки со ссылочной целостностью как раз ПОЗВОЛЯЮТ C>реализовать AWAIT в полном объеме и эффективно. В том же MLе есть C>действительно прозрачная многозадачность: C>http://portal.acm.org/citation.cfm?id=866513
C>Есть и практическая реально используемая реализация: Erlang.
Гхм...
1) В Erlang посылка сообщения является побочным эффектом. Так что как только вы начинаете говорить о параллельности, вы можете сказать ссылочной целостности "дазвиданья".
2) В Erlang не предусмотрено примитивов синхронизации. Вообще.
3) Потому, что в Erlang у процессов нет разделяемых данных. Все данные локальны для процессов.
4) И единственный способ обмена информацией между процессами — обмен сообщениями с копирующей семантикой.
5) Есть библиотека для Python, позволяющая писать в таком же стиле. Так же работал Smalltalk 72. Этот стиль не имеет практически никакого отношения ни к ФЯ, ни к прозрачности по ссылкам.
G>2) В Erlang не предусмотрено примитивов синхронизации. Вообще.
Я уже дико извиняюсь, но это не совсем так. Действительно, всяких мутексов-шмутексов там нет, но операции посылки и получения сообщения таки являются примитивами синхронизации, как ни крути.
Перекуём баги на фичи!
