aspose file tools*
The moose likes Threads and Synchronization and the fly likes Synchronized Methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Synchronized Methods " Watch "Synchronized Methods " New topic
Author

Synchronized Methods

John Eipe
Ranch Hand

Joined: May 23, 2008
Posts: 206
Hi

As i read about synchronized methods, I find that they are always used along with wait/notify. I couldn't find an example where synchronized methods alone stand to solve a problem.

Let me first post my understanding:
Synchronized methods make every operation within the method atomic. Say we have a class as shown below:


No 2 threads can simultaneously modify the variable 'c'. Java tutorials says:
However, there are actions you can specify that are atomic:
Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
Reads and writes are atomic for all variables declared volatile (including long and double variables).


So, synchronized methods come into action only when otherwise. (i.e, if the above instance variable, c had been a long data type)


www.cs-repository.info
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36579
    
  16
I think you have misunderstood it completely.
A read or a write is something like i = 123; or return i;, but what you have is four arithmetic operations and four assignments. The arithmetic is by no means atomic, so it is theoretically possible for two threads to invoke that method 0.1 nanosecond apart. they might even be executed at different speeds, so thread 2 might find c == 1 and increment that to 2, even in the time it takes thread 1 to go from the first C++; to the second C++;. And if you had more complicated arithmetic, eg c *= 97.0; c /= 97.0;, the two threads might meet when one is part-way through the arithmetic.
To be sure of your method returning 0, you would have to synchronize that method, or better still, put a Lock on it.

I think this thread would sit better in our threads forum (beware of puns), so shall move it thither.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4244
    
    7

Here's an example. Let's say you've written a singleton class using lazy initialisation like this:
In a multi-threaded environment, it's possible for the following to happen:

- Thread 1 calls getInstance(), and checks theInstance. This is null.
- Thread 2 calls getInstance(), and checks theInstance. This is null.
- Thread 1 creates an instance
- Thread 2 creates a second instance

And hey presto, you've got two instances of your singleton, which is not what you want.

If you synchronize the method (and notice that this is a static method, so it's synchronized on the class), then this can't happen. It would force the following behaviour:

- Thread 1 calls getInstance(), and checks theInstance. This is null.
- Thread 1 creates an instance
- Thread 2 calls getInstance(), and checks theInstance. This is not null, so the existing instance is returned.

And your singleton is happy again.
John Eipe
Ranch Hand

Joined: May 23, 2008
Posts: 206
Thanks a ton to Ranch and it's members! I understood it perfectly.
John Eipe
Ranch Hand

Joined: May 23, 2008
Posts: 206
I have one more question,

Is livelock same as race condition? It would be great if someone could post a snippet of code.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36579
    
  16
I presume you have found the Java™ Tutorials section; there is a header for "livelock".
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Synchronized Methods
 
Similar Threads
Atomic operation
Synchronization Methods
Synchronization uncovered
Regarding ThreadLocal and Volatile
sleep() vs suspend() and stop() vs volatile