Transferred from IBM DeveloperWorks China If you find that 99.99% of your code runs on a single CPU, it will quickly crash when you increase to two or more CPUs, then this treasure is suitable for you. . This issue is not only related to the complexity of Java code running on a symmetrical multiprocessor (SYMMETRIC MULTIPLE Processor, SMP) platform, but also related to the impact of "protected" code. Although your code should be efficient and consistent, it is always important, but because the platform such as SMP will exaggerate the consistency problem in the storage model, this is especially true when your application is running on the SMP platform. Although the dual IF clause is a general method of solving the problems caused by multi-threaded applications, it gives you a "weak consistency" model (CPU pipe technology, predictive implementation, etc.) Question (especially for SMP systems). Therefore, this treasure is short: If your application will run on the SMP system, please do not use dual if logic in your code. Now let's take a closer look at the causes and mechanisms of this issue. Double IF logic first, consider the following code to point the pointer to the resource, where Flag indicates if there is any resource: if flag == 0 {// no resource set flag acquire resource set pointer to resource} else set Pointer to resource if this The segment code is reusable (ie, can run it by multiple threads), then it is very dangerous.
Consider thinking if a thread is in the middle of the IF clause, the other thread discovers that the flash has been set, so it tries to set the resources that the pointer points to the first thread have not allocated, what? Fortunately, this problem is easy to correct, as shown below: if flag == 0 {// no resource acquire resource ----- a set pointer to resource set flag} else set pointer to resource, now we find Another problem: a thread implicit in a point, and the other thread continues to be executed by the FLAG is found to be 0. In this case, both threads perform the same paragraph code allocation resource - this is not what we hope! However, the solution is well known: We can block all other threads as long as we perform a resource code, as shown below: Enter lock if flag == 0 {// no resource acquire resource set PoinTo Resource Set Flag} Else Set Pointer to Resource Leave Lock (Note I use Lock this term to keep the sample simple. Of course, in the Java code is the synchronization code in the SYNCHRONIZE clause to represent it). Now our code is thread safe, but it is not efficient. Getting a lock (or the tube in Java) takes a lot of time, and the code in the lock is much more than what we need.
In order to correct this, we rewrite the code into the following: if flag == 0 {// no resource ----- A Enter Lock Acquire Resource Set Point To Resource Set Flag Leave Lock} Else Set Pointer To Resource This is almost However, we have introduced the previous problems, and a thread is aborted at a point, and the other thread is inserted, thus causing the chaos of the CPU. In order to correct this, we use the famous dual if clause: if flag == 0 {// no resource ----- a Enter lock if flag == 0 acquire resource set PoinTo Resource Set Flag else set Pointer to Resource Leave Lock} Else Set Pointer To Resource We have made your best efforts to secure code threads safe and efficiently by adding dual if clauses. Double IF logic is recommended to solve the thread process in many books in many advanced programming technology. However, dual if logic is not safe on a plurality of threads that can be executed simultaneously. You will say, but at a moment will only have a thread in the part of "locking", then what is the problem? a lot of! This is why this skill is called "Double IF Magic". Double IF Magic consider the impact of pipe technology on the above code: Since the CPU does not see any dependencies, you can execute the code in the IF clause in any order. This will affect the instructions marked with * below. If the FLAG is set to 0, the calculation pointer (possibly rubbish) and throws it compared to the pointer in the case of "FLAG" and then calculates Flag non-0, which may be more efficient. Therefore, the CPU can use the pipe technology to process the instructions marked with ** below.
The following is these code, in order to illustrate the above views, add the mark: ** if flag == 0 {// no resource enter lock if flag == 0 * acquire resource * set PoinTer to resource * Set Flag else set Pointer to Resource Leave Lock} Else ** Set Pointer To Resource Although it seems a bit strange, the above code may be implemented below: ** set pointer to resource ** if flag == 0 {// no Resource Enter Lock Set Pointer To resource if flag == 0 * Set flag * acquire resource ---- A * SET POINTER TO RESOURCE ELSE Leave Lock} Else As you see, our very sensitive code is still in the lock, but now sets the FLAG before allocating resources. So, please imagine the thread A is executing near A, at this moment, another thread arrives. On the SMP machine, the second thread can be executed simultaneously with the first thread on another CPU; this thread sees the FLAG is not set to 0 (because it is outside the lock), it can continue to point the pointer to unallocated Resources - it is! In addition, even if the code is implemented according to the implementation we have written, the reason is that the CPU can use the pipeline technology to process the code to be marked with **:
