Участница:Alinap95
По балансировке
Пусть в domain_node существует некий контейнер статусов узлов vector<pair<string, int>> nodeStatuses, где будет храниться адрес узла и его статут (например, 0 – занят, 1 – свободен). Когда стартует узел, он посылает сигнал о готовности в domain_node. Domain_node, в свою очередь, записывает в nodeStatuses адрес узла и его статус 1. При записи должен срабатывать триггер – если записали 1, то тут же надо посылать задание на обработку узлом, после чего присвоить 0 – узел занят. Таким образом, вектор будет иметь N ячеек по количеству узлов. По мере выполнения, каждую минуту (интервал может быть и другим) просыпается отдельно выделенный поток на каждом узле (или сделать его detached, а не вводить в сон?), который опрашивает состояние (isProcessRunning), после чего отправляет запрос на запись уже в свою выделенную ячейку о статусе (стоит ли создать мьютекс на каждую ячейку вектора?). Возможно, задания будут выполнены раньше, поэтому надо также реализовать передачу в поток сигнала о том, что задания выполнены. Возможно, стоит рассмотреть случай выхода из строя узла (если такой системы нет). Тогда имеет смысл хранить посланное задание (набор параметров и функцию). Если вышел из строя, то нужно будет послать первому свободному узлу задание отключенного узла. - Алина.
Я так понимаю, вы хотите убрать процедуру запроса состояния «пауза-запрос-снять с паузы»?
1. isProcessRunning – это метод узла или балансировщика? Процесс определен на узле, поскольку им и выполняется, иначе нужно будет вводить сведения о существующих логических процессах в балансировщик. (Логический процесс, в отличие от процесса моделирования, – элемент параллельного выполнения в терминах глобального балансировщика нагрузки).
2. А зачем узлу знать о том, что все задания выполнены? Сейчас он просто реализует сервер «получил свое задание-выполнил-уведомил балансировщик». Можно сделать это для «головного узла» (ППО на рисунке), задачей которого является взаимодействие с предметно-независимой подсистемой. Можно в балансировщике в интерфейсе ILoadBalancer реализовать метод, например, GetLoadInformation, который позволял бы атомарно (в глобальном смысле) получать информацию о количестве свободных узлов и параметрах, т.е. объединить методы ILoadBalancer::NodeCount и ILoadBalancer::ParametersTotalSize. Далее ППО на основе этих данных делала бы вывод о состоянии общего процесса моделирования. Вроде бы это позволило бы избавиться от паузы. Но на это еще надо внимательно посмотреть.
Очередь с приоритетом все равно нужна. Можно, конечно, определить ее над вектором.
Если асинхронный метод INode::StartProcess (в т.ч. на стороне прокси, реализующего коммуникацию, в распределенной конфигурации) вернул код ошибки, значит задание из балансировщика не извлекается. Но если узел задание принял, т.е. метод вернул «успех», а потом отключился, то да – задание потеряно. Если же соединение не потеряно, но ошибочно лишь выполнение логического процесса узлом, то узел может вновь поместить задание в балансировщик (такого в узле сейчас нет). Андрей Чусов (обсуждение) 09:05, 4 января 2018 (UTC)
По CUDA
Стратегия использования всех мощностей будет хорошо работать при наличии хотя бы одно устройства с CUDA; мощности позволят быстрее проводить первичную обработку. (Позволит ли разделение процесса обработки и вычисления отлавливать ошибки эффективнее?) - Алина.
По CUDA. Первичная обработка – это инициализация модели на узле? Мы посылаем устройству (CUDA) задание, вызывая ядро с параметрами, ждем результата. Во время выполнения циклов по перебору контрольных точек и созданию вторичных источников мы опять вызываем соответствующие ядра CUDA, и ждем результатов. Нам нужен будет какой-нибудь класс с интерфейсом для CPU, реализующий очередь задач (на основе очереди, создаваемых драйвером CUDA), возможно с ограниченной клиентом длиной. Опять же, если выполнение ядра дает ошибку, выполняем на CPU или генерируем ошибку узла или пытаемся выполнить вновь на CUDA позже (если синхронная функция CUDA, напр. cudaDeviceSynchronize или cudaMemcpy, дает ошибку вроде cudaErrorIllegalAddress – это нехватка ресурсов). Андрей Чусов (обсуждение) 09:05, 4 января 2018 (UTC)
По рефакторингу
Оптимизация проектов Необходимо провести рефакторинг (одинаковые сущности называются по-разному в проектах arch_ac и radio_hf). Пересмотреть модель источников. Первичный и вторичный источники являются наследниками CSourceBase и имеют некоторую направленность (например, CPatternBasedSource). Необходимо сделать так, чтобы можно было создать источник, не прибегая к сущностями типа CPrimarySource, поскольку у источников есть одни и те же методы, но некоторые поля все же отличаются (зависит от паттерна, переданного в CPatternBasedSource). (Возможно, нужно применить паттерн Декоратор?)
Идея для статьи
Переделать парсер математических выражений, сделав его объектно-ориентированным. В дальнейшем прикрутить SBO.