Tushar Goel wrote:How are you creating producers/consumers thread? Is this some home assignment?
Tim Driven Development | Test until the fear goes away
Mike. J. Thompson wrote:I'm a little confused about what exactly your requirements are here. Your producer is putting work into the queue, but you don't want the consumer to process that work once the producer has run out of input?
Well in order to do this there will need to be some form of communication between the two threads. The consumer will maintain a flag indicating whether it should continue, and the producer will set the flag to false when it is done.
You may want to look into the listener pattern that is used by graphical components in Java. You could have an interface called InputExhaustedListener. The producer will allow listeners to be registered with it, and will trigger all listeners when its input is exhausted. The creator of the threads can then register a listener with the producer that will stop the consumer when the input is exhausted.
However I think you may have a problem if your consumer quits when the queue is empty. That will create a race condition, and the consumer could exit at any time even if the producer is still running. If at any time the consumer is running faster than the producer it could empty its queue.
Tim Cooke wrote:One solution is to enhance your message protocol to include a control message that will instruct your consumer to terminate.
Tim Driven Development | Test until the fear goes away
Tim Cooke wrote:
Tim Cooke wrote:One solution is to enhance your message protocol to include a control message that will instruct your consumer to terminate.
This will only work if your queue is of type FIFO. Otherwise your consumer could pick up the control message and terminate before processing all other messages.
Tim Driven Development | Test until the fear goes away
Possibly, but not with blocking queues; it says they don't accept nulls.Roy Wood wrote: . . . I could use null as a signal but that sounds like it could have problems....
Tim Driven Development | Test until the fear goes away
Campbell Ritchie wrote:
Possibly, but not with blocking queues; it says they don't accept nulls.Roy Wood wrote: . . . I could use null as a signal but that sounds like it could have problems....
Roy Wood wrote:I am currently only using 1 producer and 1 consumer but I don't want to limit myself just in case requirements change.
Tim Driven Development | Test until the fear goes away
You right‑click the icon at the top left of the thread next to the date posted, then copy link location, paste it into the URL tags, and you get this.Chan Ag wrote: . . . I don't know how to link the specific post within a thread . . .
-- No. You're sending future developers on a wild goose chaseFuture developer wrote:Why is the poison pill going back on the queue? Are there more consumers?
-- The inconsistency reduces trust in your code.Future developer wrote:I only see one consumer, but there must be more otherwise why else put the pill back on the queue?
-- An incorrect assumption which will likely lead to unpleasantness at best, a production outage at worst.Future developer wrote:Obviously whoever wrote this has designed it for concurrency, so we can just add more producers and consumers with no other changes
Tim Driven Development | Test until the fear goes away
Tim Cooke wrote:
-- No. You're sending future developers on a wild goose chaseFuture developer wrote:Why is the poison pill going back on the queue? Are there more consumers?
.... and the other two questions and the reasons mentioned.
Sunglasses. AKA Coolness prosthetic. This tiny ad doesn't need shades:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|