Как смоделировать систему массового обслуживания HPC с Objective-C - PullRequest
0 голосов
/ 06 августа 2010

Я пытаюсь запрограммировать приложение для Mac, чтобы оно запрашивало высокопроизводительный вычислительный кластер о его работах по вычислениям и работе в очереди. Цель состоит в том, чтобы иметь возможность отслеживать отправленные задания, если они все еще находятся в очереди и ожидают выполнения или если они выполняются и на каком узле или хосте в кластере.

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

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

Обратите внимание, что я хотел бы запрограммировать его без использования CoreData, если это возможно.

DataModel

1. Возможность
Желтый объект очереди является корневым объектом моего графа объектов и владеет всеми объектами хоста (имеет NSArray пользовательских объектов хоста). Каждый хост-объект владеет всеми объектами задания, которые выполняются на этом хосте (также имея NSArray пользовательских объектов задания). Я думаю, что у этого подхода есть две основные проблемы:

  1. где хранятся все объекты заданий, которые все еще находятся в очереди и еще не запущены на хосте. Им не хватает родительского хоста.
  2. Как реализовать NSTableView, содержащий все объекты заданий?

2. Возможность
Желтый корневой объект содержит прямые ссылки на все объекты заданий, храня их в NSArray. Каждое задание имеет переменную экземпляра, сохраняющую хост-объект. Опять вот некоторые проблемы

  1. У меня также были бы узлы в модели, которые в настоящее время не используются, поэтому в настоящее время на них не выполняется никакая работа.
  2. Как реализовать источник данных для NSTableView, показывающего все хосты.
  3. Как убедиться, что нет дублирующих хост-объектов, чтобы каждый хост в кластере был представлен только одним хост-объектом.

Мои вопросы: 1. Какая из двух возможностей имеет больше смысла? Есть ли альтернативы? 2. Будет ли лучше реализовать это с CoreData? 3. Как управлять жизненным циклом объекта, чтобы не было циклов сохранения или висячих указателей.

Спасибо

1 Ответ

2 голосов
/ 06 августа 2010

Если вас беспокоит управление памятью, Core Data - это то, что вам нужно.Это намного более эффективная память, и она управляет памятью для вас в подавляющем большинстве случаев.

Обычно вы управляете памятью, следя за тем, чтобы экземпляры каждого отдельного класса очищались после себя.Затем вы помещаете объекты в иерархию таким образом, чтобы при каждом освобождении уровня он автоматически очищал находящиеся под ним объекты.

Что касается конкретной структуры, то это зависит от логики ситуации, которую вы моделируете.Если организация логически говорит:

 queue{
    jobs{
        host
    }
}

... тогда вам следует имитировать это в вашей структуре данных.

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

...