Показаны сообщения с ярлыком многопоточность. Показать все сообщения
Показаны сообщения с ярлыком многопоточность. Показать все сообщения
Варианты многопоточности в iOS
Каждое iOS приложение состоит из одного или более потока. Каждое приложение начинается с одного потока и, затем может создавать еще дополнительные потоки.
Когда приложение создает дополнительный поток, он становится отдельной сущностью в пространстве процесса приложения. Каждый поток имеет свой стек и планируется на исполнение отдельно kernel’ом. Поток может общаться с другими потоками. Все потоки находятся в общем адресном пространстве приложения и делят одну и ту же виртуальную память и имеют те же права доступа что и процесс приложения.
Главный поток приложения имеет существенные отличия от остальных по своему фнукционалу. Он выполняет функцию main приложения и отвечает за обработку событий от пользователя и обновление UI.
Поэтому, если, скажем нам нужно сделать чтото асинхронное или объемное, то желательно это сделать не в основном потоке. Если это делать на главном потоке – приложение перестанет реагировать на пользователя и с большой долей вероятности будет закрыто.
Многопоточность в iOS. Введение в GCD, часть 4, семафоры
Очередная статья о GCD. На этот раз познакомимся с семафорами, механизм которых предлагает нам GCD. Семафор позволяет выполнять какой-либо участок кода одновременно только конкретному количеству потоков. В основе семафора лежит счетчик, который и определяет, можно ли выполнять участок кода текущему потоку или нет. Если счетчик больше нуля — поток выполняет код, в противном случае — нет.
На семафоре определены три операции:
- Создание семафора
- Подождать, пока счетчик семафора станет больше нуля, уменьшить его на единицу и пройти далее
- Увеличить счетчик на единицу
Многопоточность в iOS. Введение в GCD, часть 3
В первой части мы узнали, что для выполнения задач существуют очереди. Узнали какие виды очередей существуют и как из создавать. В третьей части мы познакомимся с полезными функциями для управления очередями задач.
Вспомним, что очередь создается вот так:
dispatch_queue_t queue = dispatch_queue_create("com.myapp.myqueue", DISPATCH_QUEUE_CONCURRENT);
Далее мы будем использовать переменную queue, подразумевая что очередь у нас создана.
Многопоточность в iOS. Введение в GCD, часть 2
В прошлой статье мы познакомились с очередями выполнения задач и с некоторыми функциями, которые позволяют запускать задачи на выполнение. В этой статье мы рассмотрим еще несколько функций, которые запускают задачи на выполнение.
Многопоточность в iOS. Введение в GCD
GCD или Grand Central Dispatch — механизм распаралеливания задач, представленный в iOS 4 и Mac OS X 10.6. Суть механизма в том, что реализация многопоточности скрывается от программиста. Всю «заботу» о создании потоков берет на себя GCD. Утверждается, что задачи GCD легковесны и требуют меньше процессорного времени, чем создание потоков. Получается, что все что требуется от программиста — определить какие задачи выполнять и поставить в нужную очередь, а GCD уже разберется со всем остальным.
Дайджест по саморазвитию в программировании №13
How to monitor file access for an OS X application?
OSX VM with 2D and 3D acceleration?
13.04 installed on Parallels on OSX. Very slow graphics performance
Xcode and Asynchronous Unit Testing
Asynchronous Unit Testing in Xcode 6
XCTestCase / XCTestExpectation / measureBlock()
How Do I Declare A Block in Objective-C?
Многопоточность в iOS. Введение в GCD, часть 4, семафоры.
OSX VM with 2D and 3D acceleration?
13.04 installed on Parallels on OSX. Very slow graphics performance
Asynchronous Unit Testing in Xcode 6
XCTestCase / XCTestExpectation / measureBlock()
How Do I Declare A Block in Objective-C?
Многопоточность в iOS. Введение в GCD, часть 4, семафоры.
Устройство асинхронных фреймворков для Python
Асинхронный подход появился еще очень давно, когда надо было эмулировать параллельное выполнение задач на одноядерных процессорах и старых архитектурах.
«Асинхронность» и «параллельность» — довольно-таки ортогональные понятия, и один подход задачи другого не решает.
Тем не менее асинхронности нашлось отличное применение в наше высоконагруженное время быстрых интернет-сервисов с тысячами и сотнями тысяч клиентов, ждущих обслуживания одновременно.
Откровенно говоря, есть только два варианта работы с сокетом — синхронный и асинхронный.
С синхронным в целом все понятно — пришел клиент, открылся сокет, передали данные, если это все — сокет закрылся. В этом случае пока мы не закончили локальный диалог с одним клиентом — не можем начать его с другим. По такому принципу обычно работают простые серверы, которым не надо держать сотни и тысячи клиентов. В случае если нагрузка возрастает, но не критично — можно создать еще один или несколько потоков (или даже процессов) и обрабатывать подключения еще и в них. Это обкатанный годами, стабильно работающий подход, который, например, использует сервер Apache, — никаких неожиданностей, данные от клиентов обрабатываются в порядке строгой очереди, а в случае запуска какого-то «долгого» кода — например, каких-то вычислений или хитрого запроса в БД — это все никак не влияет на других клиентов.
Но есть проблема: сервер не может плодить потоки и процессы вечно — есть же, в конце концов, вполне ощутимые ресурсы, которые тратятся при каждом таком действии, и имеется верхний порог использования этих ресурсов. И вот тогда все вдруг вспомнили про асинхронность и системные вызовы для неблокирующего ввода-вывода. Зачем плодить кучу сокетов и потоков, выедать ресурсы, если можно данные от многих клиентов сразу одновременно слушать на одном сокете?
Заметки о многопоточности в Cocoa
Код который помещается в:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
});
работает в основном потоке, т.е. если из этого кода вызвать:
[NSThread exit];
то программа завершит своё выполнение.
Подписаться на:
Сообщения (Atom)