Нужно ли мне беспокоиться о проблемах параллелизма в моем коде Flex / AIR?
У меня есть ситуация, когда я запускаю несколько объектов, которые, когда они готовы обработать некоторые входные данные, вызывают обработчик.
Этот обработчик получает набор данных из ArrayCollection ожидающих запросов, назначает его объекту и удаляет набор данных из ArrayCollection.
(Я не могу выйти из коллекции ArrayCollection, потому что мне нужно выполнить поиск в ней, чтобы найти подходящий набор данных - он не всегда находится наверху.)
Возможно ли, чтобы два объекта могли вызвать мой обработчик таким образом, что (1) первому назначен набор данных, (2) второму назначен тот же набор данных, прежде чем экземпляр обработчика, обслуживающего первый, удалил его, и я думаю (3) второй экземпляр ошибки обработчика при попытке удалить набор данных из коллекции ArrayCollection.
Я недостаточно знаком со средой выполнения Flash Player, чтобы знать, возможен ли вообще этот сценарий отказа, или мне нужно потратить дополнительное время, чтобы установить какую-то блокировку, чтобы предотвратить его.
Обновлено: ответы на данный момент дают восторженные отзывы о Flex, но я не уверен, что они ответят на вопрос. Чтобы было ясно, я не пытаюсь решить, использовать ли Flex.
Если у меня есть метод, который:
- Получает часть данных откуда-то в коллекции ArrayCollection
- Что-то делает с этими данными
- Удаляет эти данные из коллекции ArrayCollection.
Возможно ли, что другой вызов того же метода может сделать №1 после того, как первый вызов сделает №1, но до того, как он сделает №3?
le dorfier, вы сказали, что Flex / AS «просто работает» - не могли бы вы пояснить, что в этом случае он будет «просто работать»?
Ответы 3
Вам не нужно выполнять блокировку, но вы можете отслеживать порядок изменений вашего состояния. Различные выполняемые асинхронные вызовы могут возвращать и изменять состояние вашей модели в порядке, отличном от того, когда были выполнены асинхронные вызовы.
Приложения Flex и AIR имеют однопоточную модель программирования. Однако их архитектура полагается на асинхронный ввод-вывод для взаимодействия с серверным уровнем.
Теперь в приложении Java Swing или .NET Winforms можно выполнять операции ввода-вывода в фоновом потоке и маршалировать аргументы / результаты в основной поток графического интерфейса и из него. (Эти графические библиотеки пользовательского интерфейса не позволяют другим потокам изменять состояние объектов / виджетов графического инструментария, и, следовательно, взаимодействие с данными должно быть направлено в другие потоки фоновой обработки и из них.)
Напротив, библиотека классов ввода-вывода Flex и AIR написана там, где эти классы реализуют операции ввода-вывода асинхронно. Например, для выполнения HTTP-запроса GET можно вызвать метод HttpSerivce send (), который не является блокирующим вызовом. Вместо этого может быть предоставлено закрытие ActionScript3 для обработки результата всякий раз, когда вызов в конечном итоге завершается и возвращается.
Тем временем приложение Flex / AIR может позволить графическому интерфейсу пользователя оставаться полностью интерактивным для пользователя. Он может даже отображать индикатор выполнения и / или кнопку отмены.
Таким образом, оказывается, что хотя однопоточная модель графического интерфейса пользователя Flex / AIR проще и проще в программировании, чем многопоточные приложения Java Swing или .NET Winform, она способна к тому же сложному поведению пользовательского интерфейса, что и стиль богатого интерфейса. клиентские приложения.
Простой управляемый событиями однопоточный графический интерфейс, асинхронный ввод-вывод (через вызовы служб и / или обмен сообщениями) в сочетании с закрытием ActionScript3 для обработки результатов или ошибок - это секретный рецепт Flex / AIR для мирового господства. (Конечно, я должен упомянуть хорошую поддержку свойств, событий и красивую декларативную - или императивную - привязку данных также как часть этой стратегии завоевания мира.)
После нескольких месяцев погружения в Flex и Actionscript я вернулся к .NET; и я немного потрясен всеми различными режимами, из которых мне приходится выбирать - или, наоборот, я должен выбирать и оркестрировать.
Напротив, Flex / AIR имеет практически один простой, но полный набор вызовов SDK для обработки данных и файлов, каждый с синхронным и асинхронным вариантами. Его гораздо легче понять и использовать последовательно.
Роджер прав, исходя из моего опыта. Flex / AS # просто работает. .NET, все меньше (от перегрузки опций, ИМХО). Одним из следствий этого является то, что .NET лучше подходит для пограничных сценариев; но если Flex / AS3 может удовлетворить ваши требования, он, вероятно, справится с этим легко. Подумайте о Правиле 80/20 (или, возможно, лучше).
Я думаю, что ваш вопрос был задан Роджером, но позвольте мне сказать так, как я думаю, что я его слышал.
Ваш метод является однопоточным (вместе с другими действиями пользовательского интерфейса) в общем потоке пользовательского интерфейса. Но ресурсы (файлы, порты dbms и т. д.) Обычно проходят простую последовательность, которую вы обычно настраиваете следующим образом:
- Создайте экземпляр объекта желаемого класса ресурсов,
- Зарегистрируйте обработчик события возврата для объекта (скажем, "fileonOpen"),
- Вызовите метод асинхронного выполнения для объекта (скажем, "file.open").
- Цикл событий пользовательского интерфейса продолжается,
- Ресурс в конечном итоге завершает выполнение своего метода и запускает зарегистрированный вами обработчик событий, который теперь работает в потоке пользовательского интерфейса. Возможно, ответ на ваш вопрос заключается в том, что обработчику событий предоставляется аргумент, который является объектом, к которому он относится, поэтому вы можете удалить его из своей коллекции. Предположительно, ваш объект достаточно хорошо идентифицируется, чтобы избежать путаницы при работе с коллекцией, к которой он принадлежит. Если это строка результата базы данных, она, вероятно, знает свое собственное значение PK. Файловые объекты имеют такие свойства, как nativePath, isDirectory, parent (другой объект File) и т. д.
Ответ на ваш вопрос, как вы его описали, - нет. Хотя знание о регистрации событий, диспетчеризации событий, приоритетах, асинхронности и т. д. Очень важно, факт остается фактом: вы выполняете работу по изменению коллекции ArrayCollection в рамках одной функции в основном потоке, за которой последует второй вызов этой функции также в основном потоке - так что вам не о чем беспокоиться с точки зрения параллелизма: хотя это правда, вы можете не знать, какой объект попадает туда первым (по множеству причин), вы можете быть уверен, что второй получит продукт работы, выполненной первым.
Так что нет, тебе хорошо. Раскачать!
Благодарю за разъяснение. Для моего приложения не имеет значения, в каком порядке принимаются вызовы, важно только то, что я не отправляю одни и те же данные двум вызывающим абонентам.