Как убедиться, что ваш делегат (iphone, какао) является потокобезопасным?

Question

Я видел несколько примеров использования делегата с несколькими потоками для асинхронной загрузки изображения с системой загрузки URL-адресов какао.

Я думаю, что процесс идет следующим образом.

Поток 1: giveпоток 2 - операция, которую нужно выполнить, и делегат, к которому поток 2 получит доступ после завершения.

Поток 2: после завершения операции вызывает предопределенный селектор для делегата, переданного потоком 1.

Я хотел бы реализовать аналогичную функцию (асинхронная обработка с делегатом) с моими собственными классами.Приведенный ниже псевдокод похож на описанный выше процесс, но я хотел бы сделать его более подробным для обсуждения безопасности потоков.

Поток 1:
[начать критический раздел]
установить делегат так, чтобы поток 2 мог получить доступ к
[конец критической секции]
запустить операцию

- (void) dealloc (из класса объекта делегата) {
[начать критическую секцию]
установить для делегата значение null
[конец критической секции]
}

Поток 2:
фактически работает над операцией
- после завершения .. [начать критическую секцию]
get делегат
[делегат executeSelectorOnMainThread @someSelector];
[конец критического раздела]

Теперь я беспокоюсь о безопасности потоков при доступе к делегату.Другими словами, как 2-й поток гарантирует, что делегат по-прежнему действует, когда объект делегата может исчезнуть в любое время, не дожидаясь завершения операции .

Приведенный выше псевдокодлучшая попытка, которую я сделал, и интересно, сработает ли это на самом деле.Кроме того, я никогда не видел попыток сделать поток делегата безопасным в подобной работе, такой как http://www.markj.net/iphone-asynchronous-table-image/ Разве критическая секция не требует безопасной защиты?

Спасибо

Answer 1

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

Answer 2

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

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

- (недействительно) отмена состояний соединения NSURLC:

"После вызова этого метода делегат получателя больше не будет получать никаких сообщений для этого NSURLConnection."