producer-consumer

I have two threads. Thread A is pulling some elements from queue and thread B is adding some elements to the queue. I want thread A to go to sleep when the queue is empty. When thread B adds some element to the queue it should make sure that thread A is working. How can this be done in Java? Use a BlockingQueue , which is: A Queue that additionally supports operations that wait for the queue to become non-empty when retrieving an element, and wait for space to become available in the queue when storing an element. Seriously, don't try to reinvent the wheel here. (If you must use wait/notify,

I've written background InputStream (and OutputStream ) implementations that wrap other streams, and read ahead on a background thread, primarily allowing for decompression/compression to happen in different threads from the processing of the decompressed stream. It's a fairly standard producer/consumer model. This seems like an easy way to make good use of multi-core CPUs with simple processes that read, process, and write data, allowing for more efficient use of both CPU and disk resources. Perhaps 'efficient' isn't the best word, but it provides higher utilisation, and of more interest to

I'm toying with the idea of implementing a generic Producer/Consumer pair + processing queue in C# for fun. The idea is you can just create objects that implement appropriate IProducer and IConsumer interfaces (default implementations supplied), which will consist mainly of delegates, pass them to a QueueProcessor class instance, tell it how many consumers you want, and go. But I say to myself, "Self, surely this has been done before." So does anyone know of a good , generic implementation of the producer/consumer pattern in C# (VB.Net is okay, too)? The basic requirements I'm looking for: Use

So I have seen a lot of ways of implementing one consumer and many producers in Go - the classic fanIn function from the Concurrency in Go talk. What I want is a fanOut function. It takes as a parameter a channel it reads a value from and returns a slice of channels that it writes copies of this value to. Is there a correct/recommended way of implementing this? Jeremy Wall You pretty much described the best way to do it but here is a small sample of code that does it. Go playground: https://play.golang.org/p/jwdtDXVHJk package main import ( "fmt" "time" ) func producer(iters int) <-chan int {

In the Migrating Away from Threads section of Apple's Concurrency Programming Guide, there is Changing Producer-Consumer Implementations , which claims that the typical multistep pthread mutex + condition variable implementation can be simplified using GCD. With dispatch queues, you can simplify the producer and consumer implementations into a single call: dispatch_async(queue, ^{ // Process a work item. }); When your producer has work to be done, all it has to do is add that work to a queue and let the queue process the item. The Producer-Consumer problem is also known as the Bounded-Buffer

I have an application that uses RabbitMQ as the message queue to send/receive message between two components: sender and receiver. The sender sends message in a very fast way. The receiver receives the message and then does some very time-consuming task (mainly database writing for very large data size). Since the receiver takes a very long time to finish the task and then retrieve the next message in the queue, the sender will keep filling up the queue quickly. So my question is: Will this cause the message queue to overflow? The message consumer looks like the following: public void

I'm quite new in multithreading programming, I just know the most common Producer-Consumer-Queue. I'm using the boost c++ libraries and I don't know if is better use boost::lockfree::queue or a wrapper class around std::queue that is using `mutex` and `condition_variable`. Where is better using lock free data structures and where is better is use a simple implementation based on `mutex` and `condition_variables`? Try both in your app, see which performs best. Typically, polling a lock-free queue works best when the queue nearly always has entries, a blocking queue works best when the queue is