0. Пара слов вначале
1. Откуда ноги растут
2. Активные объекты
3. Исключительный доступ
4. Возвращение после отвлечения
5. Куда путь держим?...
6. Что относительно библиотеки?
Приложение 1
Приложение 2
Приложение 3

Итак, господа и дамы, по прошествии стольких лет, сломанных копий и пустопорожних обсуждений в Сети, я таки сподобился засесть и накропать нечто, что будет очень похоже (я надеюсь) на реализацию активных объектов а ля Активный Оберон.

К моему удивлению, сделать это оказалось довольно легко. Нет, в «кишки» GCC я не полез – упоси, Господь! – пусть этим занимается, кто поумней и посвободней... :о) Легкость реализации , по-видимому, объясняется несколькими причинами. 1) знанием предмета (чего хотелось получить); 2) как оказалось (к немалому удивлению автора), не плохому знанию С/С++ и 3) желанием, наконец, дать «в народ» некий инструмент, позволяющий получить семантику Активного Оберона в более привычной, языковой и исполнительной среде. Сюда ещё стоит приплюсовать планы автора на конкретном примере «въехать», наконец, «плотненько» и, по-возможности, навсегда в POSIX-системы. Кроме того, не последнюю роль сыграла и, просто-таки гениальность спецификаций POSIX, после ознакомления и овладевания навыками работы с которыми, навряд ли кто из ПРОГРАММИСТОВ захочет возвращаться в Win32. Добавьте сюда ещё и то интеллектуальное и эстетическое удовольствие, которое получаешь, работая с ХОРОШИМИ продуктами (а ОСРВ QNX несомненно к таким относится!), и Вы поймёте, чем для меня были эти три недели работы над библиотекой, предоставляемой на ваш суд... Насколько эти все усилия и желания увенчались успехом – оценивать тебе, уважаемое сообщество... :о)

Хочу от всей души поблагодарить Евгения Зуева, Томаса Фрея и Патрика Реали, которые предоставляли материалы и консультации по Активному Оберону и Зоннону (следующей «тихой революции» из ETHZ), Егору Горошко (Draggan), за участие в конструктивных дискуссиях и всему харьковскому сообществу кьюниксоидов (http://qnxclub.net) – за то, что выдерживали мой корявый язык во время всех тех пародий на доклады и выступления по поводу активных объектов!

Ну, шо ж... «помоляся на восток», начнём пожалуй!

Назвался груздем — полезай в кузов.

Простите, кто на ком стоял? Выражайтесь яснее!

Наиболее краткое пояснение, о чём идёт речь, выглядит так: потоки, процессы, мьютексы и прочая требуха – не уровень аналитика предметной области, проектировщика архитектуры и разработчика объектов программной системы. Это – даже не уровень программиста, реализующего проектные решения, принятые на более ранних этапах. Это – слова не из словаря этих специалистов. Привлечение этих понятий происходит вынужденно. Это – «чужеродные тела» в программных системах.

while(true)
{
    ThinkAbout(SphericalHorse* horses);
}

// Псевдо-код
class MySimpleActiveObject
{
public:
    MySimpleActiveObject() : _stoped(false)
    {
        _thread = create_thread(&ThreadFunc);
    }
    ~MySimpleActiveObject()
    {
        _stoped = true;
        wait_tread(_thread);
    }

    void SomeFunc()
    {
        send_request(_request, SOME_FUNCTION);
    }

private:
    void _SomeFunc()
    {
    }

    void ThreadFunc()
    {
        while(!_stoped)
        {
            int reqCode = waite_request(_request);
            switch(reqCode)
            {
                case SOME_FUNCTION:
                    _SomeFunc();
                break;
            }
        }
    }

    handle _thread;
    handle _request;
    bool _stoped;
};

int GetValue()
{
  return this.privateValue;
}

Активный объект — это объект обладающий собственным потоком управления.

#define X_BEGIN try { X_ENTER;

#define X_END X_LEAVE; } catch(...) { X_LEAVE; throw; }

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

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();

{ File file("path");
  .....
  { File another_file("another.path");
    .....
  }
  .....
}

BEGIN_WORKING_WITH_FILE("path");
  var = read();
  write(expression());
  // как представить работу с двумя файлами сразу - загадка...
END_WORKING_WITH_FILE;

G>Вы на Эрланге хоть что-нибудь писали? Если бы писали, или хотя-бы интересовались, то знали бы, что "разделяемый ресурс" просто-напросто заворачивают в процесс . Не нужны там мьютексы, барьеры и семафоры и прочее удаление гланд через задний проход. Не думает эрланговский программист о синхронизации — нет у него таких проблем. Нет синхронизации — нет и примитивов синхронизации. А все остальное, как любил говорить мне уважаемый Трурль , существует только в вашем сознании.

@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},
}

G>>>Считать или нет операцию асинхронной посылки сообщения и блокирующую синхронную операцию получения сообщения примитивами синхронизации — вопрос глубоко философский .

АПВ>Понятие сообщения в эраланговской модели неделимо и "аксиоматично", если угодно. Куда уж атомарней-то?

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) :
С этим — да, я пропустил случай распределенных транзакций.

Synchonization Examples

Readers and Writers

Signals

Re-entrant Locks

Binary and Generic Semaphores

Barrier

Bounded Buffer

  ...
  BEGIN{EXCLUSIVE}
    ...
  END
  ...

  ...
  lock(this)
  {
    ...
  }
  ...

  ...
  System.Threading.Monitor.Enter(this);
  try
  {
    ...
  }
  finally
  {
    System.Threading.Monitor.Exit(this);
  }

BEGIN{EXCLUSIVE} //1

BEGIN{EXCLUSIVE} //2
END//1

END//2

C>BEGIN{EXCLUSIVE} //1

C>BEGIN{EXCLUSIVE} //2
C>END//1

C>END//2
C>

  ...
  a.semaphore.P();
  ...
  b.semaphore.P();
  ...
  a.semaphore.V();
  ...
  b.semaphore.V();
  ...

TYPE
  Sem* = OBJECT  (* Binary Semaphore *)
      VAR  taken: BOOLEAN
      
      PROCEDURE P*;  (* Enter semaphore *)
      BEGIN {EXCLUSIVE}
          AWAIT(~taken); taken := TRUE
      END P;
      
      PROCEDURE V*;  (* Leave semaphore *)
      BEGIN {EXCLUSIVE}
          taken := FALSE
      END V;
      
      PROCEDURE & Init;
      BEGIN  taken := FALSE
      END Init;
  END Sem;