Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Study guide: Achieve strong performance with threads, Part 2

Brush up on Java terms, learn tips and cautions, review homework assignments, and read Jeff's answers to student questions

By Jeff Friesen, JavaWorld.com, 06/07/02

Glossary of terms

critical code sections

Code sequences that let multiple threads manipulate class and instance field variables and other shared resources.

deadlock

When multiple threads acquire each others' needed locks but can't release those locks because they are both waiting to enter their respective critical code sections.

lock

A software entity that a monitor uses to prevent multiple threads from entering the monitor.

monitor

A protective wrapper around a critical code section.

race condition

The act of each thread racing to complete its critical code section before some other thread enters that critical code section.

serializing

One-at-a-time ordering.

shared variables

Class and instance field variables.

synchronization

The act of serializing thread access to critical code sections.

Tips and cautions

These tips and cautions will help you write better programs and save you from agonizing over why the compiler produces error messages.

Tips

• When you need to determine if a thread holds a given object's associated lock, call Thread's static boolean holdsLock(Object o) method. That method returns a Boolean true value if the thread calling that method holds the lock associated with the object that o references; otherwise, false returns. For example, if you were to place System.out.println (Thread.holdsLock (ft)); at the end of SynchronizationDemo1's main() method, holdsLock() would return false. False would return because the main thread executing the main() method does not use the synchronization mechanism to acquire any lock. However, if you were to place System.out.println (Thread.holdsLock (ft)); in either of run()'s synchronized (ft) statements, holdsLock() would return true because either the deposit thread or the withdrawal thread had to acquire the lock associated with the FinTrans object that ft references before that thread could enter its critical code section.
• To avoid a no-synchronization scenario, choose an object common to all relevant threads. That way, those threads will compete to acquire the same object's lock, and only one thread at a time can enter the associated critical code section.
• To avoid deadlock, carefully analyze your source code for situations where threads might attempt to acquire each others' locks, such as when a synchronized method calls another synchronized method. You must do that because a JVM cannot detect or prevent deadlock.

Cautions

• Don't synchronize a thread object's run() method because situations arise where multiple threads need to execute run(). Because those threads attempt to synchronize on the same object, only one thread at a time can execute run(). As a result, each thread must wait for the previous thread to terminate before it can access run().

Homework

Please answer the following two questions and complete the exercise:

• Can multiple threads access the same local variables or parameters? Why or why not?
• Why is synchronization important?
• The article cautions you about synchronizing the run() method. Write a program that demonstrates why you should not synchronize that method.

Answers to last month's homework

Last month, I asked you two questions. My answers appear in red.

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.