Необходимо использовать dispatch_semaphore_t в другом потоке?

#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"]);
    });
}
 

Консоль напечатала:

  1. viewDidLoad
  2. self.dataArray ===== ( 1, 2, 3 )
  3. завершение загрузки

Кроме того, это то, чего я ожидал.


Что меня беспокоило, так это то, почему в основном потоке это не сработало?Есть ли мертвая блокировка?

Комментарии:

1. Излишне говорить, что я бы не рекомендовал использовать семафоры для синхронного запуска некоторых потенциально медленных процессов. И я бы определенно не стал скрывать это за каким-либо методом доступа. Лучше всего сохранять асинхронное поведение явным (например, провести рефакторинг, чтобы полностью исключить свойство и использовать метод на основе блоков завершения, который вы будете использовать вместо свойства). В будущем вы будете благодарны себе, если просто не будете скрывать изначально асинхронное поведение за некоторым синхронным интерфейсом. Эта тупиковая ситуация — лишь один из примеров проблем, которые вы создаете с помощью этой практики.

Ответ №1:

Да, у вас была тупиковая ситуация в основной очереди. viewDidLoad вызывается в основной очереди. Итак, вы создали семафор в основной очереди.

Затем вы ожидаете семафора в основной очереди, пока выполняется асинхронный вызов.

Проблема в том, что затем вы пытаетесь вызвать dispatch_after основную очередь. Но основная очередь заблокирована в ожидании семафора. Итак, теперь у вас тупик.

При изменении dispatch_after на другую очередь вызов для передачи сигнала семафору может быть продолжен, ожидание заканчивается, и основная очередь может быть продолжена.

При работе с семафором всегда требуется вызывать signal и wait из двух разных очередей, чтобы избежать взаимоблокировки.

Ответ №2:

Есть ли мертвая блокировка

Да, точно. Несмотря на то, что вы используете dispatch_after , который является асинхронным, ваше использование семафоров подрывает асинхронность и означает, что вы эффективно пытаетесь повторно войти в основной поток из основного потока синхронно. Вы не можете этого сделать.