• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Threads

 
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please explain what happens with overriding the run method with a synchronzed run method? When you override a method, I know it checks for the paramters. But it would seem that the when you override a non-synchronized method to be synchronized, that the machine would get confused since it was not originally set up to handle locks. Please explain.
public class MyThread implements Runnable {
private String holdA = "This is ";
private int[] holdB = {1,2,3,4,5,6,7,8,9,10};
public static void main(String args[]) {
MyThread z = new MyThread();
(new Thread(z)).start();
(new Thread(z)).start();
}
public synchronized void run() {
for(int w = 0;w < 10;w++) {
System.out.println(holdA + holdB[w] + ".");
}
}
}
 
Ranch Hand
Posts: 3244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Charlie,
It would seem to me that making run() to be synchronized could have bad side effects. synchronized establishes a monitor on the object for that particular method so that not more than one object can access it at the same time. Since run() is an instance method only one object will be accessing it anyway. And as long as the thread is running then it will be locked so no other thread will be able to do anything to this object. This could be ok, but if another thread needs to interact with it in any way it probably wouldn't work. The object would in a sense lock itself.
someone corect me if I'm off base with this

Dave
 
Charlie Swanson
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave,
I ran the code, and according to the test creator this code is fine. I thought the same as you, and I don't understand why it would not do exactly what you said.
 
Dave Vick
Ranch Hand
Posts: 3244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Charlie
Now that I've thought about it and played with some code it seems to me that the way you do it in your code the lines:
<code>
(new Thread(z)).start();
(new Thread(z)).start();
</code>
actually create two threads that each have their own run method so it isn't testing what we thought. to test what we think we'd have to create a thread then call it start() method twice. like this:
<code>
public class Tester extends Thread {
Tester z = new Tester();
z.start();
z.start();
...
</code>
and doing this will throw an IllegalThreadStateException (I tried it). So I guess the whole point is moot, you can't call the run() method of a thread object a second time unless it has stopped running the first time.
Let me know if you have a different theory

Dave
 
Charlie Swanson
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dave,
The way I fiqure it the original code ones one object z. This
object is used in two different threads.
Both of these threads run fine when the overriden method is run with synchronize as a modifier. When I ran it. I got 2 counts that were uninterrupted showing that the synchronized worked.
When I took out the synchronize modifier, the code also worked; but this time it did not print out the count without being interrupted; this showed that the code ran without being synchronized.
All this is confusing still because I still don't understand how a method can be overriden with: public synchronized void run {}
when it is usually public void run {}.
It seems to contradict logic. The method being overriden was not synchronized, and therefore didn't originally have any locks associated with it. But with the overridden method, it is synchronized.
Please explain again as I still do not understand why or what exactly is happening.
Sincerely,
 
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Charlie,
When you override a method the JVM checks that the overriding method has the same return type, name, and parameter list and only throws exceptions of the same class/subclass as those declared in the original method.
The 'synchronized' keyword is not an access modifier or return type, nor is part of the name or parameter list; so the compiler ignores it for the purpose of overriding.
You can also override a synchronized method and change it to a non-synchronized method. The original superclass method will continue to be synchronized or not depending on it's original declaration.
Hope that helps.


------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
 
Charlie Swanson
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jane,
That does clear it up alot.
The access modifiers are public, protected, and private that cannot be made less private when modifiing.
Synchronized is not considered an access modifier. I guess the lock does not have to be determined by the parent.
Thanks,
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic