O'Reilly logo
  • Yang Wu thinks this is interesting:

rocessing data can potentially be a time-consuming operation, and as you saw in chapter 3, it’s a bad idea to hold a lock on a mutex for longer than necessary.

From

Cover of C++ Concurrency in Action: Practical Multithreading

Note

  1. here will cause signal lost (ie. where consumer thread processing jobs w/o holding the mutex, producer thread can signal it, and the signal will be lost) but the data will be added to the queue and test condition will be true so consume thread won't be blocked on wait next loop in.
    If it is strickly sync'd (processing with mutex hold), then we don't need a queue, just an element is enough. Using a queue to bulk up the jobs and processing w/o holding the mutex, in effect, made the design more effecient.