Здравствуйте, Сергей Губанов, Вы писали:
СГ>Серьмяжная правда заключается в повышении уровня абстракции.
СГ>На одной чаше весов находятся всего три универсальных понятия "EXCLISIVE, AWAIT, ACTIVE" на другой чаше весов находятся процессы, потоки, мютексы, мониторы, сигналы, этот Ваш scope guard, и т.д. и т.п. Весы находятся в равновесии ибо сущности равновесны. Однако: "EXCLISIVE, AWAIT, ACTIVE" — это понятия уровня проектирования, в то время как "процессы, потоки, мютексы, мониторы, сигналы, и т.д. и т.п." — это понятия низкоуровневой реализации.
Если мы отвлечёмся от топика, и обратимся к другому виду ресурса (а эксклюзивность — это ресурс) — то получим интересную аналогию.
Итак, ресурс: файл.
Если ресурс — внешний по отношению к коду, мы работаем с ним как с объектом.
В неуправляемом стиле:
File file;
file.open("path");
var = file.read();
file.write(expression());
File another_file; // одновременно с первым
another_file.open("another.path");
file.write(another_file.read());
another_file.close();
file.close();
В стиле enter-leave мы работаем с ресурсом не как с объектом, а как с субъектом.
BEGIN_WORKING_WITH_FILE("path");
var = read();
write(expression());
// как представить работу с двумя файлами сразу - загадка...
END_WORKING_WITH_FILE;
Такой стиль вполне имеет право на существование.
Например, консольный скрипт, который переключает свой вывод (stdout) в файл.
Или инструментированный скрипт на PHP, зипующий и кэширующий страницу, которую выводит его собственная подпрограмма.
Какие-то глобальные ресурсы — скажем, соединение с БД, или контекст поиска имён в скриптовом языке — вполне возможно оформлять таким способом.
Данный поток вычислений в каждый момент имеет дело с одним-единственным субъектом. Точнее, это субъект имеет дело вычислениями ;)
Во многих вычислительных средах субъектом является контекст потока. Это он занимается вычислениями, а данные, которых он касается — объекты. И, как правило, в системе есть ручки, позволяющие другим субъектам обращаться к этому как к объекту — создавать, синхронизироваться, убивать.
Такая дуальная природа контектста потока приводит к идее Активного Объекта: субъект, который формально представлен полноценным объектом вычислительной среды (т.е. экземпляром класса, с методами и прочими красивостями).
Тем не менее, для многозадачности важна именно субъектная сущность: собственное течение времени, собственные взаимодействия с ресурсами (одним из которых является эксклюзивный доступ к "собственным" данным).
Здравствуйте, zzz-zzz, Вы писали:
ZZ>Здравствуйте, Gaperton, Вы писали:
G>>2) В Erlang не предусмотрено примитивов синхронизации. Вообще.
ZZ>Я уже дико извиняюсь, но это не совсем так. Действительно, всяких мутексов-шмутексов там нет, но операции посылки и получения сообщения таки являются примитивами синхронизации, как ни крути.
Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский .
Я не считаю это примитивами синхронизации. Здесь синхронизировать нечего и незачем — у процессов просто-напросто нет разделяемых данных, и соответственно, нет необходимости контроллировать доступ к ним. Операции посылки/получения ровным счетом ничего не синхронизируют, у них соверщенно другое предназначение.
Впрочем, "хоть горшком назови, только в печь не ставь."
Здравствуйте, Трурль, Вы писали:
Т>До этого места замечательно. А дальше почему-то описывается механизм рандеву и утверждается, что именно так и должны взаимодействовать активные объекты.
Я же сказал, с точностью до названия терминов. Для Ады — это рандеву, для C++ — это будет ожидание в режиме ядра на некотором событии или порту завершения ввода-вывода.
Т>Задачи Ады, естественно, используют рандеву, но вряд-ли их можно считать объектами.
Это уже флейм получится... Модули по типу модулей Паскаля многие склонны рассматривать тоже как объекты, причём истинные объекты с абсолютной инкапсуляцией (только это относится не к объектно-ориентированной, а к объектной парадигме).
А объекты языка Vulcan (объектно-ориентированный наследник параллельного пролога) вообще ни на что не похожи...
Т>В 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
Препроцессор и 2 библиотеки — это ещё не полноценная реализация языка... Я думаю, когда Страуструп придумывал C++, он тоже мог накидать некий простой компилятор, но говорить о нём как о реализации языка смешно.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, zzz-zzz, Вы писали:
ZZ>>Здравствуйте, Gaperton, Вы писали:
G>>>2) В Erlang не предусмотрено примитивов синхронизации. Вообще.
ZZ>>Я уже дико извиняюсь, но это не совсем так. Действительно, всяких мутексов-шмутексов там нет, но операции посылки и получения сообщения таки являются примитивами синхронизации, как ни крути.
G>Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский .
G>Я не считаю это примитивами синхронизации. Здесь синхронизировать нечего и незачем — у процессов просто-напросто нет разделяемых данных, и соответственно, нет необходимости контроллировать доступ к ним. Операции посылки/получения ровным счетом ничего не синхронизируют, у них соверщенно другое предназначение.
Ну философия тут не так чтобы уж совсем бездонно глубокая.
Да, erlang'овцы действительно избавились от значительной части проблем с синхронизацией, что не удивительно: меньше разделяемых ресурсов — меньше плясок с синхронизацией. Это очень простая и прозрачная мысль.
Однако отсутствие разделяемых данных не означает, что нет вообще никаких разделяемых ресурсов. Разделяемым ресурсом в данном случае является объективная реальность, данная нам, так сказать, посредством устройств ввода/вывода. Она у нас одна и доступ к ней порой приходится синхронизировать.
Считать ли асинхронную посылку и синхронное получение примитивами синхронизации? Если всякие разные мутексы, барьеры и семафоры с их помощью тривиально реализуются, то вывод тут однозначен.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Кодт, Вы писали:
К>>Тогда в чём сермяжная правда и отличие от захвата-освобождения мутексов, практикуемого во многих средах и языках? К>>Для любителей делать begin-end блоки — в С++ предусмотрена идиома scope guard.
СГ>Серьмяжная правда заключается в повышении уровня абстракции.
СГ>На одной чаше весов находятся всего три универсальных понятия "EXCLISIVE, AWAIT, ACTIVE" на другой чаше весов находятся процессы, потоки, мютексы, мониторы, сигналы, этот Ваш scope guard, и т.д. и т.п. Весы находятся в равновесии ибо сущности равновесны. Однако: "EXCLISIVE, AWAIT, ACTIVE" — это понятия уровня проектирования, в то время как "процессы, потоки, мютексы, мониторы, сигналы, и т.д. и т.п." — это понятия низкоуровневой реализации.
Хочется заметить, что из того, что лежит на чаше "сущностей низкоуровневой реализации" всегда можно сделать то, что лежит на другой чаще.
Я если посмотреть на поток как на "поток управления", т.е. некую сущность выполняющую код, то это далеко не низкоуровневая деталь реализации.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Однако отсутствие разделяемых данных не означает, что нет вообще никаких разделяемых ресурсов. Разделяемым ресурсом в данном случае является объективная реальность, данная нам, так сказать, посредством устройств ввода/вывода. Она у нас одна и доступ к ней порой приходится синхронизировать.
АПВ>Считать ли асинхронную посылку и синхронное получение примитивами синхронизации? Если всякие разные мутексы, барьеры и семафоры с их помощью тривиально реализуются, то вывод тут однозначен.
Ну да, ну да. "Считать ли С объектно-ориентированным языком? Здесь нет никакой особо глубокой философии. Если классы с VMT тривиально реализуются на C, то вывод тут однозначен".
Вы на Эрланге хоть что-нибудь писали? Если бы писали, или хотя-бы интересовались, то знали бы, что "разделяемый ресурс" просто-напросто заворачивают в процесс . Не нужны там мьютексы, барьеры и семафоры и прочее удаление гланд через задний проход. Не думает эрланговский программист о синхронизации — нет у него таких проблем. Нет синхронизации — нет и примитивов синхронизации. А все остальное, как любил говорить мне уважаемый Трурль , существует только в вашем сознании.
Здравствуйте, Gaperton, Вы писали:
G>Вы на Эрланге хоть что-нибудь писали? Если бы писали, или хотя-бы интересовались, то знали бы, что "разделяемый ресурс" просто-напросто заворачивают в процесс . Не нужны там мьютексы, барьеры и семафоры и прочее удаление гланд через задний проход. Не думает эрланговский программист о синхронизации — нет у него таких проблем. Нет синхронизации — нет и примитивов синхронизации. А все остальное, как любил говорить мне уважаемый Трурль , существует только в вашем сознании.
Ой, вэй! Как вы мошете так говорить, когда 6 миллио^W^W самая главная статья про формальную верификацию кода на эрланге посвящена, угадайте чему? Вы будете смеяться, она посвящена resource locker'у, который представляет собой именно средство синхорнизации доступа к ресурсу.
@inproceedings{730165,
author = {Thomas Arts and Clara Benac Earle and John Derrick},
title = {Verifying Erlang Code: A Resource Locker Case-Study},
booktitle = {FME '02: Proceedings of the International Symposium of Formal Methods Europe on Formal Methods — Getting IT Right},
year = {2002},
isbn = {3-540-43928-5},
pages = {184--203},
publisher = {Springer-Verlag},
}
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Здравствуйте, Gaperton, Вы писали:
G>>Вы на Эрланге хоть что-нибудь писали? Если бы писали, или хотя-бы интересовались, то знали бы, что "разделяемый ресурс" просто-напросто заворачивают в процесс . Не нужны там мьютексы, барьеры и семафоры и прочее удаление гланд через задний проход. Не думает эрланговский программист о синхронизации — нет у него таких проблем. Нет синхронизации — нет и примитивов синхронизации. А все остальное, как любил говорить мне уважаемый Трурль , существует только в вашем сознании.
АПВ>Ой, вэй! Как вы мошете так говорить, когда 6 миллио^W^W самая главная статья про формальную верификацию кода на эрланге посвящена, угадайте чему? Вы будете смеяться, она посвящена resource locker'у, который представляет собой именно средство синхорнизации доступа к ресурсу.
Дарагой, зачем смеяться, да?
1) Доступа не к ресурсу, а к списку ресурсов.
2) Locker — это процесс, который управляет ресурсами.
3) Нужно это все для распределенных транзакций, чтобы скоординированно поменять несколько ресурсов, живущих в разных процессах.
4) Буду вам очень признателен, если вы объясните, при чем здесь сообщения, и как из всего этого следует, что операции приема и посылки можно назвать примитивами синхронизации.
Здравствуйте, Gaperton, Вы писали:
G>1) Доступа не к ресурсу, а к списку ресурсов.
Что совой об пень, что пнем об сову. Какая разница, список там или один ресурс?
G>2) Locker — это процесс, который управляет ресурсами.
Ну, процесс, ну и что? Это чему-от противоречит? Ничем он, кстати, там не управляет, он просто предоставляет API для mutual exlusion при доступе к множеству ресурсов.
G>3) Нужно это все для распределенных транзакций, чтобы скоординированно поменять несколько ресурсов, живущих в разных процессах. G>4) Буду вам очень признателен, если вы объясните, при чем здесь сообщения, и как из всего этого следует, что операции приема и посылки можно назвать примитивами синхронизации.
Операции приема и посылки — единственный способ межпроцессного взаимодействия для эрланговских процессов. Раз реализуем такую форму синхронизации, как mutual exlusion, то делаем это при помощи этих самых операций.
Здравствуйте, А почему вы спрашиваете, Вы писали:
G>>2) Locker — это процесс, который управляет ресурсами. АПВ>Ну, процесс, ну и что? Это чему-от противоречит? Ничем он, кстати, там не управляет, он просто предоставляет API для mutual exlusion при доступе к множеству ресурсов.
Это ничему особо противоречить не может, так как совершенно не относится к вопросу примитовов синхронизации. Сам локер очевидно "примитивом" не является.
G>>4) Буду вам очень признателен, если вы объясните, при чем здесь сообщения, и как из всего этого следует, что операции приема и посылки можно назвать примитивами синхронизации. АПВ>Операции приема и посылки — единственный способ межпроцессного взаимодействия для эрланговских процессов. Раз реализуем такую форму синхронизации, как mutual exlusion, то делаем это при помощи этих самых операций.
Это я понимаю . Я не понимаю, почему эти самые операции посылки-приема становятся от этого примитивами синхронизации. С такой логикой вы и ассемблерные команды, из которых межмашинный mutex собран, примитивами синхронизации обзовете .
Здравствуйте, Gaperton, Вы писали:
G>Это ничему особо противоречить не может, так как совершенно не относится к вопросу примитовов синхронизации. Сам локер очевидно "примитивом" не является.
Примитивом конечно же не является. Пример Locker'а был приведен для того, чтобы иллюстрировать тезис, что проблемы синхронизации стоят и при программировании на Erlang'е. Пусть и не так остро, как при программировании на других языках. Вообще, эрланговская модель параллелизма очень хороша и писать с ее помощью очень приятно. Но проблемы синхронизации (synchronization is coordination with respect to time) — это неотъемлемая часть параллельного программирования и полностью избежать их невозможно. В этом собственно и состоял пафос моего выступления.
G>>>4) Буду вам очень признателен, если вы объясните, при чем здесь сообщения, и как из всего этого следует, что операции приема и посылки можно назвать примитивами синхронизации. АПВ>>Операции приема и посылки — единственный способ межпроцессного взаимодействия для эрланговских процессов. Раз реализуем такую форму синхронизации, как mutual exlusion, то делаем это при помощи этих самых операций.
G>Это я понимаю . Я не понимаю, почему эти самые операции посылки-приема становятся от этого примитивами синхронизации. С такой логикой вы и ассемблерные команды, из которых межмашинный mutex собран, примитивами синхронизации обзовете .
Вы же не будете отрицать, что той самой пресловутой coordination with respect to time можно достичь посылкой сообщения?
Я понимаю, что Вас смущает. Вас смушает, что сообщения — это не только и не столько синхронизация, так? Думаю, что здесь нет никакой проблемы. Сообщения — примитивы межпроцессного взаимодействия, синхронизация — частный случай межпроцессного взаимодействия, следовательно сообщения — примитивы синхронизации в том числе.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Здравствуйте, Gaperton, Вы писали:
G>>Это ничему особо противоречить не может, так как совершенно не относится к вопросу примитовов синхронизации. Сам локер очевидно "примитивом" не является.
АПВ>Примитивом конечно же не является. Пример Locker'а был приведен для того, чтобы иллюстрировать тезис, что проблемы синхронизации стоят и при программировании на Erlang'е. Пусть и не так остро, как при программировании на других языках. Вообще, эрланговская модель параллелизма очень хороша и писать с ее помощью очень приятно. Но проблемы синхронизации (synchronization is coordination with respect to time) — это неотъемлемая часть параллельного программирования и полностью избежать их невозможно. В этом собственно и состоял пафос моего выступления.
Соглашусь, все безусловно так.
G>>>>4) Буду вам очень признателен, если вы объясните, при чем здесь сообщения, и как из всего этого следует, что операции приема и посылки можно назвать примитивами синхронизации. АПВ>>>Операции приема и посылки — единственный способ межпроцессного взаимодействия для эрланговских процессов. Раз реализуем такую форму синхронизации, как mutual exlusion, то делаем это при помощи этих самых операций.
G>>Это я понимаю . Я не понимаю, почему эти самые операции посылки-приема становятся от этого примитивами синхронизации. С такой логикой вы и ассемблерные команды, из которых межмашинный mutex собран, примитивами синхронизации обзовете .
АПВ>Вы же не будете отрицать, что той самой пресловутой coordination with respect to time можно достичь посылкой сообщения?
Посылка сообщения будет здесь лишь средством — транспортом. Убить человека можно: лопатой, кулаком, вилкой, столовым ножом, и цветочным горшком. Ничего из перечисленного оружием не является , но может стать орудием убийства. Когда вы рассматриваете нечто как оружие, вы рассматриваете это нечто вне контекста конкретного убийства. Вне этого контекста вилка — столовый прибор.
Так же и сообщение — это просто транспорт. Последством которого много чего можно организовать, в том числе и синхронизацию.
АПВ>Я понимаю, что Вас смущает. Вас смушает, что сообщения — это не только и не столько синхронизация, так? Думаю, что здесь нет никакой проблемы. Сообщения — примитивы межпроцессного взаимодействия, синхронизация — частный случай межпроцессного взаимодействия, следовательно сообщения — примитивы синхронизации в том числе.
Вот я и говорю — глубокий философский вопрос . Давайте поговорим об этом. Вам должно быть известно, что любой примитив синхронизации выразим через семафор (Дейкстра). Попробуйте сделать это с сообщениями . Как вы думаете — получится?
Здравствуйте, Gaperton, Вы писали:
АПВ>>Я понимаю, что Вас смущает. Вас смушает, что сообщения — это не только и не столько синхронизация, так? Думаю, что здесь нет никакой проблемы. Сообщения — примитивы межпроцессного взаимодействия, синхронизация — частный случай межпроцессного взаимодействия, следовательно сообщения — примитивы синхронизации в том числе.
G>Вот я и говорю — глубокий философский вопрос . Давайте поговорим об этом. Вам должно быть известно, что любой примитив синхронизации выразим через семафор (Дейкстра). Попробуйте сделать это с сообщениями . Как вы думаете — получится?
Думаю получится. Достаточно реализовать семафор. Сделать это, как вы сами догадываетесь, несложно. Сделаем процесс semaphore_server. Дальше надо рассказывать?
Здравствуйте, Gaperton, Вы писали:
G>Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский .
Ну, Дийкстра называл это "гармонично взаимодействующими процессами" и считал наиболее совершенным решением проблемы синхронизации. Тем не менее "примитивом" обычно все же называют нечто атомарное. Это не процесс и не функция, а именно объект. Поэтому я склоняюсь к отказу называть технологию гармонично взаимодействующих процессов примитивом синхронизации.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский . S>Ну, Дийкстра называл это "гармонично взаимодействующими процессами" и считал наиболее совершенным решением проблемы синхронизации. Тем не менее "примитивом" обычно все же называют нечто атомарное. Это не процесс и не функция, а именно объект. Поэтому я склоняюсь к отказу называть технологию гармонично взаимодействующих процессов примитивом синхронизации.
Понятие сообщения в эраланговской модели неделимо и "аксиоматично", если угодно. Куда уж атомарней-то?
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>>>Я понимаю, что Вас смущает. Вас смушает, что сообщения — это не только и не столько синхронизация, так? Думаю, что здесь нет никакой проблемы. Сообщения — примитивы межпроцессного взаимодействия, синхронизация — частный случай межпроцессного взаимодействия, следовательно сообщения — примитивы синхронизации в том числе.
G>>Вот я и говорю — глубокий философский вопрос . Давайте поговорим об этом. Вам должно быть известно, что любой примитив синхронизации выразим через семафор (Дейкстра). Попробуйте сделать это с сообщениями . Как вы думаете — получится?
АПВ>Думаю получится. Достаточно реализовать семафор. Сделать это, как вы сами догадываетесь, несложно. Сделаем процесс semaphore_server. Дальше надо рассказывать?
Не надо. Если сообщение — примитив синхронизации, то оно, как и любой примитив синхронизации, должен быть выразим через семафор, как показал Дейкстра. Так что достаточно выразить сообщения через семафоры .
На самом деле, вопрос получился глубоко филосовским по одной причине — не оговорено точное определение примитива синхронизации.
Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Gaperton, Вы писали:
G>>>Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский . S>>Ну, Дийкстра называл это "гармонично взаимодействующими процессами" и считал наиболее совершенным решением проблемы синхронизации. Тем не менее "примитивом" обычно все же называют нечто атомарное. Это не процесс и не функция, а именно объект. Поэтому я склоняюсь к отказу называть технологию гармонично взаимодействующих процессов примитивом синхронизации.
АПВ>Понятие сообщения в эраланговской модели неделимо и "аксиоматично", если угодно. Куда уж атомарней-то?
В рамках борьбы со флеймом, выложу сюда лог аськи. Штоб все знали, чего от тебя ждать, негодяя .
dbg (3:51 PM) :
ответил
Vlad (4:14 PM) :
Хреново ответил Сообщения через семафоры надо было выражать
Vlad (4:14 PM) :
Я тут такие сети расставил, а ты вопрос не понял
Vlad (4:14 PM) :
Обидно, слушай
dbg (4:15 PM) :
зачем? но если очень хочется, то можно, но _очень_ через жопу.
dbg (4:15 PM) :
ну переформулируй вопрос, может еще попадусь.
Vlad (4:15 PM) :
Затем, что если сообщение — примитив синхронизации, то оно, как и любой примитив синхронизации, должен быть выразим через семафор, как показал Дейкстра
Vlad (4:16 PM) :
Здесь ловушка — значение термина "примитив синхронизации".
Vlad (4:16 PM) :
Что это все-таки такое?
dbg (4:17 PM) :
ааа. ну ты сформулировал очень неоднозначно. я имел полное право не понять.
dbg (4:18 PM) :
средство синхронизации — это то с помошью чего можно синхронизироваться. вот и все. примитивность в данном случае — это "аксиоматичность", т.е. мы строим средства синхронизации из этих "аксиоматических" средств.
dbg (4:19 PM) :
кстати, разве это был дейкстра, а не хоар?
Vlad (4:19 PM) :
Ну да. Вилка — орудие убиства.
Vlad (4:19 PM) :
По моему, дейкстра — он рахработал теорию параллельных процессов.
Vlad (4:19 PM) :
Хз.
dbg (4:20 PM) :
ну да. в контексте пыряния в пузо, натурально, орудие. чего уж тут.
Vlad (4:20 PM) :
Но вилка — не оружие.
dbg (4:20 PM) :
ну, ты зачем-то выдвигаешь требование built for purpose. зачем оно тебе?
Vlad (4:21 PM) :
Затем, что с общепринятым примитивом синхронизации ты ничего не сделаешь, кроме main purpose.
А сообщения это просто транспорт — это совершенно different kind of animals.
dbg (4:22 PM) :
да ну? не сделаю? и subliminal channel на паре семафоров не построю?
Vlad (4:22 PM) :
А что это такое?
dbg (4:23 PM) :
штирлиц увидел на окне сорок горшков с геранью и рояль, прибитый к потолку. штирлиц понял, что явка провалена. этот способ коммуникации называется subliminal channel
dbg (4:25 PM) :
рассказывать, как соорудить канал передачи данных на семафорах, не надо?
Vlad (4:26 PM) : Охренеть. Передай мне строку от процесса к процессу через семафор.
Смотри.
У тебя есть сообщения. У тебя есть семафор. Ты сможешь собрать семафор на сообщениях. От этого свойства семафора не переходят на его составные элементы — сообщения (потому, что есть еще протокол и алгоритм).
dbg (4:27 PM) :
как передать один бит, надо рассказывать?
Vlad (4:39 PM) :
Причем тут бит
Vlad (4:39 PM) :
Ну расскажи
Vlad (4:40 PM) :
Тока штоб буфер сообщений был, и они асинхронно отправлялись
dbg (4:40 PM) :
ты издеваешься?
как причем? передадим один бит, передадим другой, а там, глядишь, и трока пролезла.
Vlad (4:40 PM) :
Буфер где?
Vlad (4:40 PM) :
Где асинхронность?
Vlad (4:41 PM) :
Естественно, можно передавать информацию через семафор. Если бы он не давал утечки информации, его и для синхронизации нельзя было бы использовать
dbg (4:41 PM) :
дык.
dbg (4:43 PM) :
но это все пустопорожнее. ты требуешь от меня доказать подменный тезис.
никто, и в первую очередь дейкстра ,не говорил что все примитивы синхронизации выразимы через семафор. этот тезис правильно формулируется так: "все _задачи_ синхронизации решаются с помощью семафоров".
dbg (4:45 PM) :
соотвественно, все задачи сихронизации могут быть решены и с помощью сообщений. с этом смысле сообщение — это, определенно, примитив синхронизации.
Vlad (5:06 PM) :
Сообщение — примитив обмена информацией. Синхронизация — частный случай обмена информацией.
Vlad (5:07 PM) :
Задача синхронизации одной посылкой сообщения не решить. Тебе нужен
1) Протокол обмена
2) Алгоритм.
Vlad (5:07 PM) :
Выводы. Алгоритмы — средства синхронизации.
Vlad (5:07 PM) :
Протоколы — тоже средства синхронизации.
dbg (5:08 PM) :
ну конечно. раз сообщение решает _все_ проблемы обмена, то следовательно, сообщение — примитив и синхронизации тоже.
Vlad (5:08 PM) :
Все по твоей логике. Смысла много в таких утверждениях?
dbg (5:10 PM) :
нет, не много. непонятно откуда взялось решить проблему _одной_ посылкой. не все проблемы синхронизации решаются _один_ семафором. нужет протокол и алгоритм. так что теперь и семафор — не примитив синхронизации?
Vlad (5:12 PM) :
Тем не менее, один семафор (и другие примитивы синхронизации — их много) решает вполне конкретную проблемы синхронизации.
Vlad (5:12 PM) :
А одно сообщение — нет.
Vlad (5:13 PM) :
Ладно, скажи — RPC-вызов — примитив синхронизации?
Vlad (5:13 PM) :
RPC совершенно эквивалентен сообщениям.
dbg (5:14 PM) :
почему нет?
можно синхронизироваться (скоординироваться во времени)? можно. значит это средство синхронизации. примитив? ну если в некоторой модели — это атомарно, неделимое событие, то да примитив.
Vlad (5:15 PM) :
На то, кстати, семафор и "примитив", что он _один_ решает проблему синхронизации. Но это совсем не "примитив" передачи информации , черта лысого ты ее так просто передашь.
А сообщение — примитив передачи информации, но далеко не "примитив" синхронизации — в один ход ты ничего не синхронизируешь.
Vlad (5:16 PM) :
Короче, терминологический спор. Зануда ты.
dbg (5:18 PM) :
ну да, зануда. а ты кто?
впрочем, о пустом спорим. я влез в дискуссию только по одному поводу. это когда ты начал рассказывать, что эрлангу проблемы синхронизации чужды, потому что у него есть сообщения и нет общей памяти. но с этим мы вроде порешили.
Vlad (5:18 PM) :
С этим — да, я пропустил случай распределенных транзакций.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, А почему вы спрашиваете, Вы писали:
АПВ>>Здравствуйте, Sinclair, Вы писали:
S>>>Здравствуйте, Gaperton, Вы писали:
G>>>>Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский . S>>>Ну, Дийкстра называл это "гармонично взаимодействующими процессами" и считал наиболее совершенным решением проблемы синхронизации. Тем не менее "примитивом" обычно все же называют нечто атомарное. Это не процесс и не функция, а именно объект. Поэтому я склоняюсь к отказу называть технологию гармонично взаимодействующих процессов примитивом синхронизации.
АПВ>>Понятие сообщения в эраланговской модели неделимо и "аксиоматично", если угодно. Куда уж атомарней-то? G>В рамках борьбы со флеймом, выложу сюда лог аськи. Штоб все знали, чего от тебя ждать, негодяя .
G>
...
Ай-ай-ай, падонак. Раскрыл инкогнитО. Я бы еще пару дней понудел бы.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Хочется заметить, что из того, что лежит на чаше "сущностей низкоуровневой реализации" всегда можно сделать то, что лежит на другой чаще.
И наоборот.
Synchonization Examples
Readers and Writers
Signals
Re-entrant Locks
Binary and Generic Semaphores
Barrier
Bounded Buffer
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Хочется заметить, что из того, что лежит на чаше "сущностей низкоуровневой реализации" всегда можно сделать то, что лежит на другой чаще.
СГ>И наоборот.
СГ>
СГ>Synchonization Examples
СГ>
Readers and Writers
СГ> Signals
СГ> Re-entrant Locks
СГ> Binary and Generic Semaphores
СГ> Barrier
СГ> Bounded Buffer
Перекуём баги на фичи!
.
. Как вы думаете — получится? 
Я бы еще пару дней понудел бы. 
