Java Thread (ix): condition-more efficient way to thread communication

Original: http://blog.csdn.net/ghsau/article/details/7481142

Nearly a week did not update the "Java Thread" column, mainly this week work more busy, life is also busy, hehe, into the topic, the previous chapter on the Lock,lock can better solve the thread synchronization problem, make it more object-oriented, And Readwritelock is more powerful when it comes to synchronizing, then again, it is not enough to have a mutual exclusion between threads, but also to communicate, this article is based on the previous article, using lock how to handle thread communication.

So introducing the protagonist of this article, condition,condition the object monitor method (wait, notify, and Notifyall) into distinct objects to provide multiple waits for each object by combining these objects with any Lock implementation Set (Wait-set). Where Lock replaces the use of the Synchronized method and the statement, Condition replaces the use of the Object monitor method. The following example of a thread communication previously written is replaced with a condition implementation (Java thread (c)), the code is as follows:

[Java]View Plaincopy

2. Public class ThreadTest2 {
4. public static void Main (string[] args) {
6. final Business business = new Business ();
8. New Thread (new Runnable () {
10. @Override
12. public Void Run () {
14. Threadexecute (Business, "Sub");
16. }
18. }). Start ();
20. Threadexecute (Business, "main");
22. }
24. public static void Threadexecute (Business business, String Threadtype) {
26. For (int i = 0; i < ; i++) {
28. try {
30. if ("main". Equals (Threadtype)) {
32. Business.main (i);
34. } Else {
36. Business.sub (i);
38. }
40. } catch (Interruptedexception e) {
42. E.printstacktrace ();
44. }
46. }
48. }
50. }
52. Class Business {
54. private Boolean bool = true;
56. Private Lock lock = new Reentrantlock ();
58. private Condition Condition = Lock.newcondition ();
60. public /*synchronized*/ void main (int loop) throws interruptedexception {
62. Lock.lock ();
64. try {
66. While (bool) {
68. Condition.await ();  //this.wait ();
70. }
72. For (int i = 0; i < ; i++) {
74. SYSTEM.OUT.PRINTLN ("main thread seq of" + i + ", loop of" + loop);
76. }
78. bool = true;
80. Condition.signal ();  //this.notify ();
82. } finally {
84. Lock.unlock ();
86. }
88. }
90. public /*synchronized*/ void sub (int loop) throws interruptedexception {
92. Lock.lock ();
94. try {
96. While (!bool) {
98. Condition.await ();  //this.wait ();
100. }
102. For (int i = 0; i < i++) {
104. System.out.println ("Sub thread seq of" + i + ", loop of" + loop);
106. }
108. BOOL = false;
110. Condition.signal ();  //this.notify ();
112. } finally {
114. Lock.unlock ();
116. }
118. }
120. }

In condition, replace wait () with await (), replace notify () with signal (), replace Notifyall () with Signalall (), traditional thread communication, condition can be implemented, here note, condition is bound to lock, the condition must be newcondition () method to create a lock.

In this view, condition and traditional thread communication is no different, the condition is that it can create different condition for multiple threads, the following introduces a piece of code in the API to illustrate.

[Java]View Plaincopy

2. Class Boundedbuffer {
4. Final Lock lock = new Reentrantlock (); Lock Object
6. final Condition notfull = Lock.newcondition (); //write thread condition
8. final Condition notempty = Lock.newcondition (); //Read thread condition
12. final object[] items = new object[]; Cache queue
14. int putptr/* Write index */, TAKEPTR/* Read Index */, Count*/* Number of data present in queue */;
18. public void put (Object x) throws interruptedexception {
20. Lock.lock ();
22. try {
24. While (count = = items.length)//If the queue is full
26. Notfull.await (); //Block write thread
28. ITEMS[PUTPTR] = x; //Assigned value
30. if (++putptr = = items.length) Putptr = 0; If the write index is written to the last position in the queue, then set to 0
32. ++count; //number + +
34. Notempty.signal (); //wake-up Read thread
36. } finally {
38. Lock.unlock ();
40. }
42. }
46. Public Object Take () throws interruptedexception {
48. Lock.lock ();
50. try {
52. While (count = = 0)//If the queue is empty
54. Notempty.await (); //block read thread
56. Object x = items[takeptr]; //value
58. if (++takeptr = = items.length) Takeptr = 0; If the read index is read to the last position in the queue, then set to 0
60. --count; //number--
62. Notfull.signal (); //wake-up Write thread
64. return x;
66. } finally {
68. Lock.unlock ();
70. }
72. }
74. }

This is a multi-threaded working environment of the buffer, buffer provides two methods, put and Take,put is the data, take is the data, there is a cache queue, the specific variables and methods described in the code, the buffer class implementation of the function: there are multiple threads to store data inside and fetch data from it, Its cache queue (FIFO first out) can cache the maximum value is 100, multiple threads are mutually exclusive, when the cache queue stored in the value of 100, the write thread block, and wake the read thread, when the cache queue is stored in the value of 0 o'clock, the read thread block, and wake the Write thread, The following is an analysis of the code execution process:

1. A write thread executes, calls the Put method;

2. Determine if count is 100, apparently not 100;

3. Continue execution, deposit value;

4. Determine if the current write index position + + is equal to 100, equality will write the index value to 0, and will count+1;

5. Only the wake-up read thread is blocking one of the queues;

6. A read thread executes, calling the Take method;

7 .....

8. Only the wake-up write thread is blocking one of the queues.

This is the power of multiple condition, assuming that the cache queue is full, then the blocking is definitely a write thread, wake Up is definitely a read thread, on the contrary, the blocking is definitely a read thread, the wake is definitely a write thread, then assume that only one condition will have what effect? Cache queue is already full, this lock does not know whether to wake up the read thread or write thread, if the wake is a read thread, happy, if the wake is a write thread, then the line Cheng Gang is awakened, and is blocked, then to wake up, so that wasted a lot of time.

Java Thread (ix): condition-more efficient way to thread communication