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

Question

Вот ленивая загрузка массива:

@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;
    }
}

Я хочу, чтобы при вызове метода-получателя dataArray было проверено, равно ли оно nil. Если 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 только . И все userInteractionEnabled отключены.

Однако, если я изменю метод загрузки данных на:

+ (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. загрузка закончена

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

---

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

Answer 1

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

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

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

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

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

Answer 2

Есть ли врезной замок

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