NSThread поднимает очередь и обрабатывает ее - PullRequest
1 голос
/ 13 апреля 2011

У меня есть приложение, которое должно отправлять собранные данные каждые X миллисекунд (и НЕ раньше!).Моей первой мыслью было сложить данные на NSMutableArray (array1) на thread1.Когда thread2 завершит ожидание X миллисекунд, он заменит NSMutableArray на новый (array2), а затем обработает его содержимое.Однако я не хочу, чтобы thread1 дополнительно модифицировал array1, как только thread2 его получил.

Это, вероятно, сработает, но безопасность потоков - это не та область, в которой вы хотите "просто попробовать".«.Каковы подводные камни в этом подходе, и что я должен делать вместо этого?

(Кроме того, если thread2 на самом деле является экземпляром NSTimer, как изменится проблема / ответ? Все ли это произойдет в одном потоке [что было бы хорошо для меня, так как обработка занимает крошечную долю миллисекунды]?).

Ответы [ 2 ]

1 голос
/ 13 апреля 2011

Вы должны использовать NSOperationQueue или Grand Central Dispatch. По сути, вы создадите операцию, которая получит ваши данные и загрузит их по истечении X миллисекунд. Каждая операция будет независимой, и вы можете настроить очередь относительно количества одновременных операций, которые вы разрешаете, приоритета операций и т. Д.

Документы Apple по параллелизму должны помочь:

http://developer.apple.com/library/ios/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html

0 голосов
/ 21 июля 2011

Подводные камни этого подхода связаны с тем, когда вы «меняете» NSArray на новый.Представьте, что thread1 получает ссылку на массив, и одновременно thread2 меняет массивы и заканчивает обработку .Thread1 теперь записывает в мертвый массив (который больше не будет обрабатываться), даже если это всего за несколько миллисекунд.Способ избежать этого, конечно же, заключается в использовании синхронизированных блоков кода (т. Е. Сделать ваш код «потокобезопасным») в критических разделах, но довольно сложно не преодолеть пометку и не синхронизировать слишком много кода.(жертвуя производительностью).

Таким образом, вы рискуете:

  • Создание кода, который не является поточно-ориентированным
  • Создание кода, который чрезмерно синхронизируется и работает медленно(и потоки уже снижают производительность)
  • Сделайте некоторую комбинацию из этих двух: медленный, небезопасный код.

Идея состоит в том, чтобы «перейти от потоков», что и есть эта ссылка о.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...