jQuery in Action, 3rd edition
The moose likes Threads and Synchronization and the fly likes Call to non-sync method form sync method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Call to non-sync method form sync method" Watch "Call to non-sync method form sync method" New topic

Call to non-sync method form sync method

Pooja K

Joined: Oct 27, 2000
Posts: 7
These statements were there in one of the previous posts:-
1) "If a synchronized method calls a non-synchronized instance method to modify and object, it is thread safe. This is because a non-synchronized method becomes synchronized when it is called from a synchronized method. "
2) "If a synchronized method directly modifies objects that are part of the private instance data of a method's class the code is not thread safe."
To check case 1, I wrote the following code:-
class prod implements Runnable{
int i =0;
synchronized void call_inc(){
void inc(){
while(i!= 15)
System.out.println(Thread.currentThread().getName() + " inc ---> " + i);
public void run(){
synchronized void dummy(){
System.out.println("dummy is being exceuted by " + Thread.currentThread().getName());

public class demo_3{
public static void main(String args[]){
prod p = new prod();
Thread t= new Thread(p);
System.out.println("Main Over");

However , on executing it, I found that sometimes main & the other executing Thread (Thread 0) printed the same value of I , which means the call to the method inc from the synchronized method call_inc() was not synchronized automatically. Please correct me, if possible with an example.
Also I have not understood the second statement..Can anyone please explain it with an example.
Thanks in advance ,
Frank Carver

Joined: Jan 07, 1999
Posts: 6920
The Java Ranch has a naming policy, described here and "Pooja K" is not a valid name. Please choose one which meets the requirements.

Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
joshua karn

Joined: Nov 08, 2000
Posts: 2
Dear sheriff,
i feel the ranch guys gotta go a bit easy on the naming policy especially on the initial.i dont see any thing wrong with using u'r initial as second name.u might put off a lot of good people.
Originally posted by Frank Carver:
The Java Ranch has a naming policy, described here and "Pooja K" is not a valid name. Please choose one which meets the requirements.

Frank Carver

Joined: Jan 07, 1999
Posts: 6920
This has been discussed many times, over the years.
There are several reasons why we have this naming policy. The first, as discussed in the link, is that we wish to maintain a serious and business-like image at all times. In most countries of the world, that means both a familiar name and a family name, and not abbreviations or crazy nicknames.
The second reason is very practical - to help reduce the chance of your name being used by someone else. My name is Frank Carver, but there are also several other users who could legitimately claim "Frank C"; so we require full names to help prevent this problem. It's not a complete solution, but it's much better than allowing abbreviations.
Finally, we want people to get recognition from others for the posts they make, be they good or bad. One of the best ways to achieve that is to require real, full, names. People are a lot less likely to be abusive to others if their real name is attached to the post; likewise it can pay to be helpful - a present or future colleague or manager may be reading and recognize your name.
This policy was not imposed lightly, and, as far as we can tell, has not dissuaded many people from joining in. We feel that the benefits greatly outweigh the disadvantages, and will therefore continue with the policy.
Rob Whelan
Ranch Hand

Joined: Oct 18, 2000
Posts: 33
To answer the original question...
You are misunderstanding that previous post. When a thread accessing a synchronized method, it grabs a "lock" for that method. Until it exits that synchronized method (regardless of what methods it calls while inside it), it keeps that lock. There is only one lock, so other threads trying to call any synchronized methods on that object must wait.
So... your thread "t" takes the lock while it's in "call_inc()" (and still has the lock while calling "inc()"), but the main thread doesn't NEED it to just call "inc()", so it goes ahead.
I agree. Here's the link: http://aspose.com/file-tools
subject: Call to non-sync method form sync method
It's not a secret anymore!