Здравствуйте, remark, Вы писали:

С>>>Ну и много ли имеется вариантов по данному вопросу? Когда произвольная схема многопоточности (каждый поток может взаимодействовать с любым другим), когда актеры могут произвольным образом между собой связываться и взаимодействовать... Вот как в такой системе управлять их временем жизни и при этом, по-возможности, не заставлять пользователя следить за этим самостоятельно?

E>>Пользователю в любом случае придется как-то помечать уже не нужные ему актеры. Автор фреймворка должен будет только определиться с тем, как пользователь будет это делать: вызывать какой-нибудь deregister_actor или delete в C++, или занулять ссылку на актера в языке с GC. А остальное уже дело техники.

R>смарт поинтер не рассматривается?

Дело не в смарт-пойнтере, это всего лишь частный случай указателя.
Я о другом говорю. Стэн ведет речь об агентной системе, в которой агенты/актеры хранят ссылки (указатели, смарт-пойтнеры) на себя. Т.е. каждый актер знает своих клиентов непосредственно, без использования каких-либо форм косвенной адресации (в виде имен или идентификаторов). Т.е., предположим у нас есть два агента: producer и consumer:

class producer : public actor
  {
  private :
    consumer * m_consumer;

  public :
    void on_some_event()
      {
        // Что-то произошло, consumer-у нужно отослать данные.
        m_consumer->send( new data( ... ) );
      }
  };

class consumer : public actor
  {
  private :
    producer * m_producer;

  public :
    void on_data( const data * msg )
      {
        // Обработка данных...
        // Заставляем producer-а выдать следующую порцию данных.
        m_producer->send( new get_next_data( ... ) );
      }
  };

Теперь, предположим, что producer-у нужно изъять из системы своего consumer-а. Он должен дать фреймворку какое-то указание о том, что значение producer::m_consumer больше не актуально (хотя на этого consumer-а могу ссылаться другие агенты). Выбрать как это указание будет выполняться -- задача дизайнера фреймворка.

Здравствуйте, eao197, Вы писали:

R>>смарт поинтер не рассматривается?

E>Дело не в смарт-пойнтере, это всего лишь частный случай указателя.
E>Я о другом говорю. Стэн ведет речь об агентной системе, в которой агенты/актеры хранят ссылки (указатели, смарт-пойтнеры) на себя. Т.е. каждый актер знает своих клиентов непосредственно, без использования каких-либо форм косвенной адресации (в виде имен или идентификаторов). Т.е., предположим у нас есть два агента: producer и consumer:
E>Теперь, предположим, что producer-у нужно изъять из системы своего consumer-а. Он должен дать фреймворку какое-то указание о том, что значение producer::m_consumer больше не актуально (хотя на этого consumer-а могу ссылаться другие агенты). Выбрать как это указание будет выполняться -- задача дизайнера фреймворка.


Почему же о другом?

class producer : public actor
  {
  private :
    agent_handle<consumer> m_consumer;

  public :
    void on_some_event()
      {
        // Что-то произошло, consumer-у нужно отослать данные.
        m_consumer->send( new data( ... ) );
      }

    void on_stop()
      {
        m_consumer.reset();
      }
  };

Здравствуйте, remark, Вы писали:

R>>>смарт поинтер не рассматривается?

E>>Дело не в смарт-пойнтере, это всего лишь частный случай указателя.
E>>Я о другом говорю. Стэн ведет речь об агентной системе, в которой агенты/актеры хранят ссылки (указатели, смарт-пойтнеры) на себя. Т.е. каждый актер знает своих клиентов непосредственно, без использования каких-либо форм косвенной адресации (в виде имен или идентификаторов). Т.е., предположим у нас есть два агента: producer и consumer:
E>>Теперь, предположим, что producer-у нужно изъять из системы своего consumer-а. Он должен дать фреймворку какое-то указание о том, что значение producer::m_consumer больше не актуально (хотя на этого consumer-а могу ссылаться другие агенты). Выбрать как это указание будет выполняться -- задача дизайнера фреймворка.


R>Почему же о другом?

А потому, что кроме подхода Стэна, где агенты хранят ссылки/указатели друг на друга, возможен и другой подход к организации связей между агентами. Через косвенную адресацию в виде имен/идентификаторов агентов. В случае подхода Стэна неизбежны какие-то формы указателей, хоть голые, хоть смарт-пойнтеры. Но при другом подходе -- это уже не важно.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, remark, Вы писали:

R>>>>смарт поинтер не рассматривается?

E>>>Дело не в смарт-пойнтере, это всего лишь частный случай указателя.
E>>>Я о другом говорю. Стэн ведет речь об агентной системе, в которой агенты/актеры хранят ссылки (указатели, смарт-пойтнеры) на себя. Т.е. каждый актер знает своих клиентов непосредственно, без использования каких-либо форм косвенной адресации (в виде имен или идентификаторов). Т.е., предположим у нас есть два агента: producer и consumer:
E>>>Теперь, предположим, что producer-у нужно изъять из системы своего consumer-а. Он должен дать фреймворку какое-то указание о том, что значение producer::m_consumer больше не актуально (хотя на этого consumer-а могу ссылаться другие агенты). Выбрать как это указание будет выполняться -- задача дизайнера фреймворка.


R>>Почему же о другом?

E>А потому, что кроме подхода Стэна, где агенты хранят ссылки/указатели друг на друга, возможен и другой подход к организации связей между агентами. Через косвенную адресацию в виде имен/идентификаторов агентов. В случае подхода Стэна неизбежны какие-то формы указателей, хоть голые, хоть смарт-пойнтеры. Но при другом подходе -- это уже не важно.


Регистр отображает имя агента на указатель, при этом он атомарно инкрементирует счётчик ссылок, либо возвращает 0, если такого агента нет.
Я не вижу тут никаких принципиальных отличий. Так это может выглядеть для пользователя:

void on_msg()
{
  handle<my_agent> h = register().get_agent("foo");
  if (!h) 
    ...;
  // ... Здесь пользуемся агентом
  // в конце функции деструктор handle освобождает ссылку
}

Или так внутри фреймворка, если мы не хотим показывать пользователю никакие указатели/хэндлы (случай SObjectizer):

bool so_send_msg(string name, msg m)
{
  handle<my_agent> h = register().get_agent("foo");
  if (!h) 
    return false;
  so_send_msg_internal(h, m);
}

Я паталогически не вижу ничего, что как-то принципиально отличалось бы от однопоточного случая и "синхронной" системы...

Здравствуйте, remark, Вы писали:

R>Я паталогически не вижу ничего, что как-то принципиально отличалось бы от однопоточного случая и "синхронной" системы...

Похоже, мы вообще говорим о разных вещах
Если есть желание продолжить, то можно сделать это в частной переписке.

Здравствуйте, eao197, Вы писали:

E>Про управление памятью говорил, есть такое дело. Хуже всего с этим у GDI библиотек, но там, вероятно, своя специфика.
E>А вот высокоуровневых С++ библиотек, в которых бы утекали другие ресурсы (GDI хендлы, сокеты, мутексы и пр.) не видел. Хотя приходилось объединять, например, Qt и Crypto++, ACE с Qt, ACE с FOX Toolkit и пр.

Ты говорил (почти дословно), что испытывал немалые проблемы из-за того, что в одной программе был вынужден использовать разные библиотеки. Мол у них были разные прирципы контроля памяти трудно совместимые между собой.

Здравствуйте, VladD2, Вы писали:

E>>Про управление памятью говорил, есть такое дело. Хуже всего с этим у GDI библиотек, но там, вероятно, своя специфика.
E>>А вот высокоуровневых С++ библиотек, в которых бы утекали другие ресурсы (GDI хендлы, сокеты, мутексы и пр.) не видел. Хотя приходилось объединять, например, Qt и Crypto++, ACE с Qt, ACE с FOX Toolkit и пр.

VD>Ты говорил (почти дословно), что испытывал немалые проблемы из-за того, что в одной программе был вынужден использовать разные библиотеки. Мол у них были разные прирципы контроля памяти трудно совместимые между собой.

Еще раз повторю -- да такое было. Но не было чтобы библиотеки ресурсы теряли. А ведь именно о потери ресурсов (т.к. GDI объекты и пр.) шла речь здесь

Автор: FR
Дата: 19.12.07

.