#ios #objective-c #grand-central-dispatch
#iOS #objective-c #grand-central-dispatch
Вопрос:
Вот отложенная загрузка массива:
@property (nonatomic, strong) NSArray *dataArray;
- (NSArray *)dataArray {
if (!_dataArray) {
// if array is nil,load data
dispatch_semaphore_t signal = dispatch_semaphore_create(0);
[DataManager loadListSuccess:^(NSArray * _Nonnull list) {
self->_dataArray = list;
dispatch_semaphore_signal(signal);
} failure:^{
dispatch_semaphore_signal(signal);
}];
dispatch_semaphore_wait(signal, DISPATCH_TIME_FOREVER);
return _dataArray;
} else {
return _dataArray;
}
}
Я хочу, чтобы при вызове метода getter dataArray
проверялось, равно ли оно нулю.Если nil, загрузите данные, затем верните.Если нет, вернитесь напрямую.
Ниже приведен код загрузки данных:
(void)loadListSuccess:(void (^)(NSArray *list))success failure:(dispatch_block_t)failure {
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
success(@[@"1", @"2", @"3"]);
});
}
В viewDidLoad:
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
NSLog(@"viewDidLoad");
NSLog(@"self.dataArray ===== %@", self.dataArray);
NSLog(@"load finish");
}
Консоль печатала только viewDidLoad .И все пользовательские взаимодействия отключены.
Однако, если я изменю метод загрузки данных на:
(void)loadListSuccess:(void (^)(NSArray *list))success failure:(dispatch_block_t)failure {
dispatch_queue_t queue = dispatch_get_global_queue(0, 0);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)),queue, ^{
success(@[@"1", @"2", @"3"]);
});
}
Консоль напечатала:
- viewDidLoad
- self.dataArray ===== ( 1, 2, 3 )
- завершение загрузки
Кроме того, это то, чего я ожидал.
Что меня беспокоило, так это то, почему в основном потоке это не сработало?Есть ли мертвая блокировка?
Комментарии:
1. Излишне говорить, что я бы не рекомендовал использовать семафоры для синхронного запуска некоторых потенциально медленных процессов. И я бы определенно не стал скрывать это за каким-либо методом доступа. Лучше всего сохранять асинхронное поведение явным (например, провести рефакторинг, чтобы полностью исключить свойство и использовать метод на основе блоков завершения, который вы будете использовать вместо свойства). В будущем вы будете благодарны себе, если просто не будете скрывать изначально асинхронное поведение за некоторым синхронным интерфейсом. Эта тупиковая ситуация — лишь один из примеров проблем, которые вы создаете с помощью этой практики.
Ответ №1:
Да, у вас была тупиковая ситуация в основной очереди. viewDidLoad
вызывается в основной очереди. Итак, вы создали семафор в основной очереди.
Затем вы ожидаете семафора в основной очереди, пока выполняется асинхронный вызов.
Проблема в том, что затем вы пытаетесь вызвать dispatch_after
основную очередь. Но основная очередь заблокирована в ожидании семафора. Итак, теперь у вас тупик.
При изменении dispatch_after
на другую очередь вызов для передачи сигнала семафору может быть продолжен, ожидание заканчивается, и основная очередь может быть продолжена.
При работе с семафором всегда требуется вызывать signal
и wait
из двух разных очередей, чтобы избежать взаимоблокировки.
Ответ №2:
Есть ли мертвая блокировка
Да, точно. Несмотря на то, что вы используете dispatch_after
, который является асинхронным, ваше использование семафоров подрывает асинхронность и означает, что вы эффективно пытаетесь повторно войти в основной поток из основного потока синхронно. Вы не можете этого сделать.