Don't understand the use of a semaphone in an init

Question

+(instancetype) objectWithAttribute:(NSString *)attribute {    

__block id newInstance;
    dispatch_semaphore_t s = dispatch_semaphore_create(0);
    dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void){
        newInstance = [[Object alloc] initWithAttribute:attribute];
        dispatch_semaphore_signal(s);
    });
    dispatch_semaphore_wait(s, DISPATCH_TIME_FOREVER);
    return newInstance;

}

So I came across this block of code. I have a very limited understanding of semaphores and concurrency in general. But to me, this code:

Sets a semaphore token.
dispatch_async a block that initialises an object.
signals once the object has been created that the new instance can be returned.

I reached this conclusion from reading the marked answer here: Intangible Order of Execution (dispatch_semaphore_t, dispatch_group_async) and the Use of Them in Combination with Different Dispatch Queue Types

If you follow through into the init and the logic there, there's nothing that goes outside normal flow or onto a new thread or anything. My question is this, why can't I replace the above method with:

+(instancetype) objectWithAttribute:(NSString *)attribute {

    id newInstance = [[Object alloc] initWithAttribute:attribute];
    return newInstance;

}

Thanks

Apart from forcing Object's init method to execute on something other than the main thread, there really doesn't seem to be much point to this. As you say the calling thread will be blocked until signaled at the end of the block, so there really doesn't seem to be any benefit to jumping through these hoops. — Casey Fleser, Nov 20 '14 at 15:02
I'd agree that, all other things being equal, you'd use your second pattern. But I'd want to see what `initWithAttribute` is doing before passing final judgment, though. There's serious code smell with this method and I would want to make sure that this `objectWithAttribute` implementation wasn't a failed attempt to address some other, more fundamental problem in the code before I yanked it out. The original author presumably contorted himself for some reason, so let's see if we can figure out why. Often, when I see something very weird like this, it's a symptom of broader problem. — Rob, Nov 20 '14 at 15:22
Where's attribute coming from? Is it from some memory location that you don't want to change while the init is going on? If the initWithAttribute accesses something in the calling object (maybe referenced through attribute) that you need to keep constant during the init process, that could possibly be a reason. — Owen Hartnett, Nov 20 '14 at 15:43

score 0 · Accepted Answer · answered Nov 20 '14 at 15:02

That use of a semaphore and dispatch_async on a background queue seems totally pointless. It should be what you think it should be.

The use of the semaphore might have made sense if the code being called was already an asynchronous call. But there was no reason to force the alloc/init to the background.

Don't understand the use of a semaphone in an init

1 Answers1