Producer-Consumer Problem

Assume that we have two kinds of processes: producer and consumer. For now, we will have one from each of them.

Producer will produce information whereas consumer will consume the information. Both will continue their function infinitely. Two problems will be raised:

  • The memory will be shared by both.
  • Both do not know the size of the buffer.

The first problem would cause 202112061109 which would affect the follow-up execution by either the producer or the consumer.

The second problem will cause difficult troubles for producer and consumer. From the producer’s perspective, it might produce more information than needed or allowed which will cause memory out of bound. From the consumer’s perspective, it might continue its consumption even there is no information available which could result in undefined behaviour.

Neither of these problems are desirable.

Solution

To fix these, we have two solutions:

  • Safeguard the shared memory by implementing mutex.
  • Checking on the buffer to determine whether it is full or empty by implementing semaphore.
Links to this page
  • Socket Programming
  • Rust Channel

    Since Rust uses the model of message passing (same as 202203021733) as a mean of thread synchronisation, a channel must be established for the threads to communicate with each other. The standard library std::sync::mpsc (mpsc stand for multiple producer single consumer#) provides the function mpsc::channel that could create a channel, which will define transmitter(s) (the one that sends messages) and receiver (the one that receives messages). The return type will be a tuple, the first element represents transmitter(s), the second element represents receiver. Combining with #202207171541, we can send a message from a thread (via transmitter’s method send) to the main thread (via receiver’s method recv or try_recv).

  • Multithreading Management

    Multithreading becomes important as the number of core for the processor increases. This allows the possibility of parallelism and concurrency# along with their limitation# and short comings# with the utilisation of threads#. 202201301240# is one of the thinking model hinting on a better parallel and/or concurrency programming.

  • Concurrency

    Hungry consumer model, advocated by Hunt et al., emphasises the use of services: independent, concurrent objects encapsulated behind well-defined consistent interfaces, instead of favouring a central scheduler among consumers#. In this way, they will consume tasks from a work queue without bothering others’ business, and if they finished, they will grab some more from the queue. Let’s say that a consumer task get bogged down because of large input data, others will just pick up the slack. It allows every consumer to proceed data in their own pace.

#multithreading