This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes synchronized and Thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Reply locked New topic
Author

synchronized and Thread

Mike Anakin
Greenhorn

Joined: Aug 02, 2007
Posts: 17
which will be the right answer ? and why ?

IMAGE REMOVED ILLEGAL COPY
[ August 08, 2007: Message edited by: Burkhard Hassel ]
Deepak Jain
Ranch Hand

Joined: Aug 05, 2006
Posts: 637
A) false, Because it does compile
B) false, as there are no runtime exceptions

When you say the class is thread safe you want to prevent variable x from getting accessed by other threads when one of the thread is about to modify the data in x. So you need a single [ONLY ONE] lock object across the threads to ensure this.

C) is false , making run() synchronized would make the currently executing TestSeven object as the lock object and since multiple threads are created instantiating TestSeven , this will actually have individual TestSeven objects as lock objects for each thread and this will not protect the variable x



The above code creates 100 threads and start them and here run() is synchtonized since the synchronization is applied at the method level the currently running TestSeven object will behave as lock objects so here there are 100 lock objects one each for each thread and this will not protect the variable x, The aim is to get a o/p 1,2,3,4 .... 98,99,100 and this is not achieved with the above code.
4) FALSE , The data variable is not protected, Run the program and display the value of x in doThings() and you will not see 1,2,3,4 .... 98,99,100 [ in sequence]

e) This is correct. When you make doThings() static and apply synchronized keyword, the lock object is the class object that loaded this class and now when you create 100 threads and since you have a single class the lock object would be the same class object across all 100 threads and you will see the the value of x as 1,2,3,4 .... 98,99,100 and hence data is now protected

f) this is incorrect because new Object() will be created for each of the 100 threads and you will not have a single lock object.

RULE OF THUMB : To protect data in critical section you must have a single lock object across threads.

Thanks
Deepak
[ August 08, 2007: Message edited by: Burkhard Hassel ]

SCJP, SCWCD, SCBCD
Mike Anakin
Greenhorn

Joined: Aug 02, 2007
Posts: 17
what does these words mean ?


Threads calling non-static synchronized methods in the same class will only block each other if they're invoked using the same instance. That's because they each lock on this instance, and if they're called using two different instances, they get two locks, which do not interfere with each other. ---comes form 'Java Study Guide'


can someone give me an example for above words .
[ August 04, 2007: Message edited by: Mike Anakin ]
Priyam Srivastava
Ranch Hand

Joined: Oct 29, 2006
Posts: 169

what does these words mean ?


Threads calling non-static synchronized methods in the same class will only block each other if they're invoked using the same instance. That's because they each lock on this instance, and if they're called using two different instances, they get two locks, which do not interfere with each other. ---comes form 'Java Study Guide'


Consider thios code::



In the above code when the doStuff() is called by threads t1 and t2, then both these thread will block each other. This is because they both are trying to obtain the lock on same object i.e. mt1, since both have been passed m1 in their constructor. Hence they will block each other.

Remember when we synchronize a method then we always obtain a lock on this instance, i.e the instance calling that method.

But thread t3 and t4 won't block each other because they are obtaining a lock on two different object mt1 and mt2.


"History would be kind to me, for I intend to write it."
Mike Anakin
Greenhorn

Joined: Aug 02, 2007
Posts: 17


but I ran these code fine , and these code input fine.
It seems that t1 and t2 will not block each other.

[ August 05, 2007: Message edited by: Ulf Dittmer ]

[ August 05, 2007: Message edited by: Mike Anakin ]
[ August 05, 2007: Message edited by: Mike Anakin ]
Deepak Jain
Ranch Hand

Joined: Aug 05, 2006
Posts: 637


Here first set of threads will not corrupt the data x with each other and the second set of threads will not corrput the data x with each other , However i dont understand why shoundnt the first and second set of threads corrput the data across each other. First set has mt1 has lock object and second set has mt2 as lock object, So when i look across the threads they are diffrent lock objects and hence two threads from each set can enter the doStuff() and try and corrput x, But when i run the code the output of x comes in correct sequence 1,2,.... 198,199,200. However if the threads were constructed by extending Thread class it would have corrupted x as shown in my earlier code. Why isnt the same behavior observed if implementing Runnable interface.
Can someone explain this.
Thanks
Deepak
Manfred Klug
Ranch Hand

Joined: Jun 04, 2007
Posts: 377
Originally posted by Deepak Jain:
However if the threads were constructed by extending Thread class it would have corrupted x as shown in my earlier code. Why isnt the same behavior observed if implementing Runnable interface.
If you have 100 threads that access the same variable at the same time, the data corruption is much more probable than if you have only two. Whether the corruption occurs, depends only on the thread scheduling. Modify the doStuff method as follows and you may see the problem.
[ August 05, 2007: Message edited by: Manfred Klug ]
 
 
subject: synchronized and Thread