views:

53

answers:

2

Hello! I have a producer and a consumer. Producer fills its internal queue with objects, consumer takes these objects one by one. I want to synchronize the cosumer with the producer, so that the consumer blocks when there are no objects ready, and I want to synchronize the producer with itself, so that it stops producing when the queue is full (and starts again when there’s space). How do I do that? I was able to solve a simpler case without the queue using NSConditionalLock, but with the queue the problem looks more complex.

A: 

I ended up using two semaphores, objectsReady and bufferFreeSlots:

@implementation Producer

- (id) getNextObject {
    [objectsReady wait];
    id anObject = [[buffer objectAtIndex:0] retain];
    [buffer removeObjectAtIndex:0];
    [bufferFreeSlots signal];
    return [anObject autorelease];
}

- (void) decodeLoop {
    while (1) {
        [bufferFreeSlots wait];
        [buffer push:[self produceAnObject]];
        [objectsReady signal];
    }
}

@end

The bufferFreeSlots is initialized to the maximum queue size. So far it seems to work, but God knows this is an act of faith, not a solid confidence.

zoul
+1  A: 

You might consider using a pair of NSOperationQueues or dispatch queues. Have your production operations (in the producer queue) send messages, on the main thread if necessary, to an object that adds consumption operations to the consumer queue.

Peter Hosey
I need the producer to stop when the buffer is full (= contains four objects, for example) and start when there is space again. The semaphores take care of that quite nicely. Can I do the same thing with a dispatch queue?
zoul
I'm not sure what you mean by “buffer”; are you talking about the queue of consumption operations? You can set an NSOperationQueue's max operation count; it will run no more than that many operations at a time. I don't think you can do this with GCD.
Peter Hosey
The producer is usually faster than the consumer, so I keep a queue of the produced objects. I want this queue to stay small because of memory constraints. This means that the producer has to stop when this queue is big enough and get running again once the consumer takes an object out of the queue. The queue’s max operation count does not seem to help with that.
zoul
zoul: You can observe the consumer queue's `operationCount` and suspend the producer queue when it goes too high, and un-suspend it when it goes back down to a comfortable level.
Peter Hosey
Aha, you’re right, thanks (+1).
zoul