java-Preliminary Understanding-14th chapter-Inter-threading communication-multi-producer multi-consumer problem-jdk1.5 Solution

One.

In version 1.5, the original form was changed, but the functionality did not change, so what was the reason for doing so?

Previously, we had a lock with only a set of monitors that monitored both the producer and the consumer. This set of monitors can wait for both producers and consumers, as well as to awaken producers and consumers alike. or notify, it can also wake up one of the threads, and one of them is not sure who it is, it could be the party, or it could be the other.

Now our threads are categorized, a group responsible for production, and a group responsible for consumption. We want producers to awaken consumers and consumers to awaken producers. If you have two monitors, a group of monitoring producers, a group of monitoring consumers, this is a reliable.

How it used to be, the producer had to have a lock, and the consumer had to have another lock, because a lock had only one monitor, and now one locked with multiple monitors. Now we have four threads with the same lock, but the monitor is different, is two monitors, a monitoring producer, a monitoring consumer. Production here is to take the wake of consumption, wake up is the consumption of the thread.

If it is two locks, then the production can only be used for production, consumption can only be used for consumption (this is said in the previous practice), they can both run at the same time, will cause problems.

And we now produce inside in the operation of time, consumption is not moving, this is called the same lock.

Producer_con producer Monitor, Consumer_con consumer Monitor.

A lock hangs with multiple monitors. Producer Monitor Monitor is the producer, wake Up is the other side ?

java-Preliminary Understanding-14th chapter-Inter-threading communication-multi-producer multi-consumer problem-jdk1.5 Solution