Мой подход. Ядро - Движок. - страница 147

Новый комментарий
 

В общем, задача почти определилась.

  1. Нужно, чтобы каждая копия советника создавала два своих ресурса, - один для записи сообщений движку, другой, для чтения сообщений от движка.
  2. Движок должен делать цикл по ресурсам, чтобы узнать, сколько копий советника запущены на разных парах.
  3. Движок создаст динамичный список запущенных советников, через который пользователь будет переключать соединение.
  4. Далее, Движок запишет имена ресурсов для передачи сообщений и для приема сообщений от советников.

  1. Каждый советник будет работать штатно, и записывать свои сообщения движку в обычном порядке. Но движок прочтет эти сообщения, только после подключения к этому советнику.
  2. На событии подключения к советнику, Движок будет посылать ему комманду, и тот запишет индивидуальное ядро парамеров в ресурс.
  3. Движок загрузит это ядро. Далее, сделает цикл по элементам GUI и перерисует их, чтобы они несли актуальную информацию.
  4. После этого, Движок будет записывать свои сообщения советнику в его ресурс для приема сообщений.

На данный момент, все советники обращаются к Движку через один общий ресурс. Задача в том, чтобы у каждого советника был индивидуальный ресурс для общения с Движком. А движок мог бы переподключать ресурсы разных советников.
 
Меня смущает,что, допустим, 5 советников будут передавать полный объем рабочих пакетов, если движок работает с шестым. Нужно на время запретить остальным пятерым передавать рабочую информацию. Пусть просто "слушают эфир".
 
Oleg Papkov:
Меня смущает,что, допустим, 5 советников будут передавать полный объем рабочих пакетов, если движок работает с шестым. Нужно на время запретить остальным пятерым передавать рабочую информацию. Пусть просто "слушают эфир".

Согласен. Это разумно. 

Значит, они будут работать штатно, но записывать сообщения в ресурс не будут. Только в копию ядра параметров. А при подключении, запишут ядро параметров в ресурс и Движок его загрузит. После подключения, советник начнет записывать сообщения для Движка в ресурс сообщений.

 

Вопрос в подключении.

Движок выставляет малую строку-адрес всем советникам. Отзывается ядро в советнике с таким же адресом опознавания и автоматически начинается  стандартная работа движок-советник. При переключении в движке на другой советник, движок переводит ядро советника, с которым работал в состояние ожидания адреса, как и другие советники в этот момент. В такой момент отцеплены все советники и ждут выставления движком другого адреса другого нужного движку советника.

Ядро нового советника откликается и переходит в состояние стандартной работы. До следующего посыла движком строки конца работы и перехода в состояние ожидания. Просто советники должны кроме стандартного обмена постоянно анализировать поток на появление в нем строки конца работы. В начале пакетов обмена должна стоять строка, указывающая кому адресован пакет передаваемый с движка. То ядро и принимает пакет управления и начинает отсылать пакеты своего состояния с заданной частотой.

Остальные ждут обращения к ним через уникальную для каждого советника строку опознавания. При переключении, движок посылает текущему советнику строку конца работы. Советник прекращает что-либо отсылать и переходит в состояние распознавания своей строки опознавания , являющейся одновременно запуском стандартной работы обмена с движком.

 
Oleg Papkov:

Вопрос в подключении.

Движок выставляет малую строку-адрес всем советникам. Отзывается ядро в советнике с таким же адресом опознавания и автоматически начинается  стандартная работа движок-советник. При переключении в движке на другой советник, движок переводит ядро советника, с которым работал в состояние ожидания адреса, как и другие советники в этот момент. В такой момент отцеплены все советники и ждут выставления движком другого адреса другого нужного движку советника.

Ядро нового советника откликается и переходит в состояние стандартной работы. До следующего посыла движком строки конца работы и перехода в состояние ожидания. Просто советники должны кроме стандартного обмена постоянно анализировать поток на появление в нем строки конца работы. В начале пакетов обмена должна стоять строка, указывающая кому адресован пакет передаваемый с движка. То ядро и принимает пакет управления и начинает отсылать пакеты своего состояния с заданной частотой.

Остальные ждут обращения к ним через уникальную для каждого советника строку опознавания. При переключении, движок посылает текущему советнику строку конца работы. Советник прекращает что-либо отсылать и переходит в состояние распознавания своей строки опознавания , являющейся одновременно запуском стандартной работы обмена с движком.

C ресурсами несколько проще. Там адреса не нужно, только наименование ресурса. У вас получилась усложненная модель. Все проще.

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

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


Кстати, мне удалось убыстрить связь и уменьшить торможение. Но до конца причины торможения еще не понял. Оно появляется при перерисовке, но странность в том, что перерисовка сама по себе не тормозит. А перерисовка при общении через ресурс тормозит. Причина пока не ясна.

 

Какой-нибудь мониторинг временных затрат поставте. Что бы видеть, где тормозит. И как это объехать.

Может я и усложнил маленько. Я же не знаю, как у вас там внутри движка организовано. Просто логикой пользовался.

 
Oleg Papkov:

Какой-нибудь мониторинг временных затрат поставте. Что бы видеть, где тормозит. И как это объехать.

Может я и усложнил маленько. Я же не знаю, как у вас там внутри движка организовано. Просто логикой пользовался.

Логика приблизила вас к сути, и в общем, вы понимаете правильно.  

Сегодня попробую разобраться в причинах торможения. Ясно следующее, - сама перерисовка не тормозит. Запись и чтение ресурса тоже. А вместе, - получается торможение. 

 
Есть мониторинг, какая операция сколько длится? Они должны последовательно выполняться. В советнике они, снятие данных и отправка в движок выполняются с частотой, допустим 30мс. Когда выполняется отправка потока в движок, тот готов принять? Или чем он занимается?
 
Oleg Papkov:
Есть мониторинг, какая операция сколько длится? Они должны последовательно выполняться. В советнике они, снятие данных и отправка в движок выполняются с частотой, допустим 30мс. Когда выполняется отправка потока в движок, тот готов принять? Или чем он занимается?

Сейчас все проверяю.

Движок на частоте 30мс читает ресурс сообщений от советника, а советник, на той же частоте, читает ресурс сообщений от Движка. На этой же частоте, они оба записывают свои сообщения друг другу (если есть что записывать). Все это не вызывает торможения. Также, перерисовка сама по себе, не вызывает торможение. 

Однако, торможение появляется, если комбинируются перерисовка и запись/чтение ресурса на стороне Движка. Причина пока непонятна. Выясняю. 

 
Реter Konow:

Сейчас все проверяю.

Движок на частоте 30мс читает ресурс сообщений от советника, а советник, на той же частоте, читает ресурс сообщений от Движка. На этой же частоте, они оба записывают свои сообщения друг другу (если есть что записывать). Все это не вызывает торможения. Также, перерисовка сама по себе, не вызывает торможение. 

Однако, торможение появляется, если комбинируются перерисовка и запись/чтение ресурса на стороне Движка. Причина пока непонятна. Выясняю. 

Может рассоглассованость: и советник и движок, 1- оба передают друг другу, 2 - оба принимают, их OnTimer циклы не синхронизированны. Ждут момент случайной синхронизации нормальной работы. Может из-за этого?

1...140141142143144145146147148149150151152153154...184
Новый комментарий