File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes More Java 5 Questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "More Java 5 Questions" Watch "More Java 5 Questions" New topic
Author

More Java 5 Questions

Sundeep Gupta
Greenhorn

Joined: Feb 28, 2006
Posts: 13
Question 1:
yield() allows other thread of same priority or threads with priority higher than it, to run.

Is this correct or Only threads of same priority are considered?

Question 2:

Using threads within a program may make exact path of execution unpredictable. true or false? How?

Anyone plz clear this doubt.

Question 3:

To be overridden a method must have same name, parameter type (combinedly called Signature) and same return type. correct or not?
i think not coz return type can be Covariant type also. SO what is correct answer?

Thanks,

Sundeep


SCJP 5.0
Graham Walsh
Greenhorn

Joined: Mar 08, 2006
Posts: 23
I would have said false here. There's nothing unpredictable about the path of execution, it's the scheduling thats uncertain. Not the code path. Think about it... unpredictable code path => java goes haywire and does whatever it wants. That's not the case. Definitely false.

Question 2:

Using threads within a program may make exact path of execution unpredictable. true or false? How?

Anyone plz clear this doubt.
Barry Bassi
Ranch Hand

Joined: Dec 20, 2005
Posts: 49
Hi Sundeep.
I try to answer to your question (but I'm only a fresh SCJP certified, not a great Java expert )

1) No. I suppose the answer is "same priority or higher priority". Anyway it's not guaranteed that the VM take care of a yeld() invocation.
2) Yes. You can try to control the execution path with syncronization, join(), wait(), notify(), etc methods.
3) No. Because of covariant types (in Java 5)

Regards,
Barry


SCJP 5.0, SCWCD 1.4, SCBCD 1.3, MySQL 5 Developer, ZCE, EUCIP Core<br /> <br />OCA 9i (in progress..)<br />SCJD UrlyBird (in progress..)
Prad Schikanov
Ranch Hand

Joined: Feb 28, 2006
Posts: 47
Sandeep,

The following description is based on the assumption that JVM implements PRIORITY SCHEDULING when it concerns with threads.

The perception behind the PRIORITY SCHEDULING is that the THREAD SCHEDULER will always run the threads with higher priorities over threads with lower priorities. According to my view that is 100% guranteed. Otherwise the implementation of priority scheduling is outrageous. With that hypothesis I feel I can give you a precise explanation.

As with thread yield(), we give the scheduler the option of selecting a thread out of equally prioritized threads to run.

The following is what would happen when you call yield() in your program.

1. JVM stops the currently executing thread. (100% guranteed)

2. JVM reads the priority of the just stopped thread. (100
% guranteed)

3. JVM search the ready pool for equally prioritized threads. (100% guranteed)

4. Then the scheduler will decide what to run out of those equally prioritized threads.

Worst case : Scheduler picks up the just-stopped-thread again to run.

Best case : Scheduler prefers diversity....!

Regards,
Priyanka.

[ March 09, 2006: Message edited by: Priyanka Kolamba Patabendige ]
[ March 09, 2006: Message edited by: Priyanka Kolamba Patabendige ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19062
    
  40

Question 1:
yield() allows other thread of same priority or threads with priority higher than it, to run.

Is this correct or Only threads of same priority are considered?


If the system is working correctly, there should be *no* higher priority threads in a runnable state. The OS should choose a higher priority thread to run, regardless of whether your thread call yield() or not.

Of course, you can say "What about Windows, which allows lower priority threads to run, in order to prevent starvation?". Unfortunately, if you use that argument, you can also conclude that yield() will allow a lower priority thread to run.

Bottom line. Calling yield() will ask the threading system to yield() the current thread, which will be honored most of the time. The system will pick the next thread to run.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19062
    
  40

The perception behind the PRIORITY SCHEDULING is that the THREAD SCHEDULER will always run the threads with higher priorities over threads with lower priorities. According to my view that is 100% guranteed. Otherwise the implementation of priority scheduling is outrageous. With that hypothesis I feel I can give you a precise explanation.


Well, maybe it is 100% guaranteed at the OS level -- debateable.

What is not debateable is that the priority of a thread at the OS level may not the priority of a thread that you set. For example, in Windows, the priority of a thread is further adjusted based on current execution time, and time from last execution. This means that what you see as a lower priority thread in the JVM, can be temporarly considered as a higher priority thread by the OS.

Henry
Prad Schikanov
Ranch Hand

Joined: Feb 28, 2006
Posts: 47
Hi Henry,


-----------------------------------QUOTE------------------------------------

Calling yield() will ask the threading system to yield() the current thread, which will be honored most of the time. The system will pick the next thread to run.

----------------------------------------------------------------------------

My idea is that in normal circumstances (with out an explicit call to thread yield()) the scheduler will continue to run the prevailing thread AS LONG AS IT DOES NOT FALL behind the priorities in the runnable pool. Given at a clock interrupt even if the scheduler finds that there are equal priority threads in the runnable pool it will continue carrying the current thread as long as it doesn't fall behind.

If yield() does nothing but giving a manual interrupt for the schduler I think there is no purpose of having that method..!

My perception is Henry, yield() does something else other than just a conventional interupt for the scheduler. May be yield() is driven by an algorithm concerning the recent execution history of equally prioritized threads and etc.... and thereby chosing a thread with a reason.


-----------------------------------QUOTE------------------------------------

Of course, you can say "What about Windows, which allows lower priority threads to run, in order to prevent starvation?".

----------------------------------------------------------------------------

I think it is really sad that Java specification doesn't tell anything precise about what implementation they use regarding threads. Whether the thread management in kernel space (to my view NO), User space or JVM maps Java threds directly to OS threads.



Please give your comments Henry..

Regards,
Priyanka.
[ March 09, 2006: Message edited by: Priyanka Kolamba Patabendige ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19062
    
  40

My idea is that in normal circumstances (with out an explicit call to thread yield()) the scheduler will continue to run the prevailing thread AS LONG AS IT DOES NOT FALL behind the priorities in the runnable pool. Given at a clock interrupt even if the scheduler finds that there are equal priority threads in the runnable pool it will continue carrying the current thread as long as it doesn't fall behind.


This used to be true in older JVMs. With newer JVMs, the threading is tied to the OS. And in most modern OSes, including Windows, Linux, and Solaris, the threads will be time-sliced, in addition to being pre-empted based on priorities.

If yield() does nothing but giving a manual interrupt for the schduler I think there is no purpose of having that method..!

My perception is Henry, yield() does something else other than just a conventional interupt for the scheduler. May be yield() is driven by an algorithm concerning the recent execution history of equally prioritized threads and etc.... and thereby chosing a thread with a reason.


Not sure what you mean by this...

I think it is really sad that Java specification doesn't tell anything precise about what implementation they use regarding threads. Whether the thread management in kernel space (to my view NO), User space or JVM maps Java threds directly to OS threads.


Hard call. In older JVMs, which uses green threads, it was cool. You could actually write your own scheduler, and manage threads the way you want it. But I am not convinced that this is a good thing anymore. Isn't it the job of the OS to manage resources optimally?

Henry
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

Q3 To be overridden a method must have same name, parameter type (combinedly called Signature) and same return type. correct or not?
i think not coz return type can be Covariant type also. SO what is correct answer?


return turn type can be a subclass of the overriding method. However, if the method you are "overriding" is private in the parent class, then you aren't overriding the method, because the subclass would never had had it in the first place.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Prad Schikanov
Ranch Hand

Joined: Feb 28, 2006
Posts: 47
Henry,



Bottom line. Calling yield() will ask the threading system to yield() the current thread, which will be honored most of the time. The system will pick the next thread to run.



Well, thread yield() must have a mechanism of deciding which fellow to pick, I guess it doesn't select a thread randomnly..! Honestly, I haven't found any meticulous elaborations of the thread yield() method. What ever the explanations I have heard it just says, yield() method itself is unpredictable. It's alright being unpredictable but what makes it unpredictable is inconclusive. For me, I don't like to keep yield() method just as an abstraction.

The question is how exactly the yield() method decides which fellow to run? Well if it just does nothing special (apart from stopping the currently running thread for a moment) what's the purpose of keeping such a method? Atleast, that was the point I was trying to make..!




Hard call. In older JVMs, which uses green threads, it was cool. You could actually write your own scheduler, and manage threads the way you want it. But I am not convinced that this is a good thing anymore. Isn't it the job of the OS to manage resources optimally?



Absolutely. I agree with you. It's the job of the OS to manage resources optimally. Having said that, are kernel threads efficient as user space threads with little or more overhead around? I know for exception Linux's kernel space threads perform nearly as well as user space threads. But is that true for all the other OSs? However I agree it's the OS's job. That is not to overide my belief in a fully fledged mobilizable language to be self sufficient.

Thanks a lot for treating me with updated information which I think, is not that easy to find.

Regards,
Priyanka.
Amit Goyal
Ranch Hand

Joined: Feb 21, 2006
Posts: 95
Hey,

As of i know:

"JVM uses PRIMITIVE PRIORITY SCHEDULING"

"That suggests there should be no Runnable thread of priority less then the priority of currently running thread."

So,

A thread can voluntarily yield the CPU by calling the yield method, which gives other threads of the same priority a chance to run. If no equal-priority threads are Runnable, yield is ignored.



Cheers!
Prad Schikanov
Ranch Hand

Joined: Feb 28, 2006
Posts: 47
>> Amit,

Well, that's the abstraction we all know. Copy instruction would copy a file to a given destination. Cut instruction would move a file to a given destination.

What I'm looking for is the underlying mechanism(or say the algorithm) behind the yield() method. What certificates that threads of equal priorities should have to be qualified to get the nod from the scheduler?



Regards,
Priyanka.
[ March 09, 2006: Message edited by: Priyanka Kolamba Patabendige ]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19062
    
  40

Well, thread yield() must have a mechanism of deciding which fellow to pick, I guess it doesn't select a thread randomnly..! Honestly, I haven't found any meticulous elaborations of the thread yield() method. What ever the explanations I have heard it just says, yield() method itself is unpredictable. It's alright being unpredictable but what makes it unpredictable is inconclusive. For me, I don't like to keep yield() method just as an abstraction.

The question is how exactly the yield() method decides which fellow to run? Well if it just does nothing special (apart from stopping the currently running thread for a moment) what's the purpose of keeping such a method? Atleast, that was the point I was trying to make..!


In the newer JVMs, yield() doesn't do anything other than causing the current thread to give up it's timeslice. It doesn't have a mechanism to pick the next thread to run -- not even randomly.

Quite frankly, to the JVM, yield() is an abstraction -- meaning it's a request to the OS. The OS "decides which fellow to run". And hopefully, the OS doesn't do it randomly...

Henry
Prad Schikanov
Ranch Hand

Joined: Feb 28, 2006
Posts: 47
Henry,

That's about it. Your elaborations have been exceptional and I really enjoyed the conversation. Great..!



Regards,
Priyanka.
[ March 09, 2006: Message edited by: Priyanka Kolamba Patabendige ]
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8883
    
    5
For those of you who might be panicking out there A lot of this conversation is way out the scope of the real exam. The real exam is based entirely on what is guaranteed by ALL JVM's. You won't ever have to know anything like 'what a typical JVM does'.

carry on


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: More Java 5 Questions