2010-08-05 2 views
0

Я пытаюсь запрограммировать приложение для mac, чтобы запросить высокопроизводительный вычислительный кластер о его запущенных и поставленных в очередь задачах расчета. Цель состоит в том, чтобы иметь возможность отслеживать отправленные задания, если они все еще поставлены в очередь и ждут выполнения или если они запущены, и на каком узле или узле в кластере.Как смоделировать систему массового обслуживания HPC с Objective-C

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

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

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

DataModel

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

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

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

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

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

Спасибо

ответ

2

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

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

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

queue{ 
    jobs{ 
     host 
    } 
} 

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

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

+0

Вы делаете хорошие моменты об этой проблеме. Я был удивлен, что даже в этом простом примере это не так просто, как я думал, не используя CoreData. Спасибо за ваши мысли. – GorillaPatch

+0

Простые обычно просто означают «знакомые». С моей точки зрения, все это очень «просто» и что-то, что я мог создать буквально через полчаса. У Core Data есть кривая обучения, но как только вы преодолеете «горб», чтобы получить это прямо в голове, тогда это создает проблемы, подобные этому тривиальным. – TechZen

Смежные вопросы