• 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

Thread.yield question for the Cowgirl

 
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome back Cowgirl!
The Thead.yield method is controversial. The API Specification states the following and nothing more.


Causes the currently executing thread object to temporarily pause and allow other threads to execute.


A number of thread tutorials offer a more detailed description.


A thread can voluntarily yield the CPU without going to sleep or some other drastic means by calling the yield method. The yield method gives other threads of the same priority a chance to run. If there are no equal priority threads that are runnable, then the yield is ignored.


Some thread schedulers are more concerned with thread priority than others. Is the API Specification intentionally vague on the behavior of Thread.yield to allow for the possibility that a time slice scheduling system might assign a different interpretation to the behavior of Thread.yield?
What assumptions should be made for the purposes of the exam? Would the statement quoted from the Thread tutorial be considered true or would it be considered overly presumptuous? Is the statement quoted from the API Specification the only statement that is guaranteed to be true concerning the Thread.yield method?
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dan,
I even read recently that the yield method gives other threads of the same priority or HIGHER PRIORITY a chance to run
 
Dan Chisholm
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe that yielding to a thread of "the same or higher" priority is a more likely implementation than one that yields only to threads of exactly the same priority as suggested by the earlier quote from the tutorial. At this point, I assume that the tutorial offers an imprecise description of a particular thread scheduler that is probably not representative of all thread schedulers.
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, gosh, I don't know about the exam... ; )
But we have a saying around here, "If it's good enough for Gosling...."
And Gosling (or one of his co-authors, but we lump them all in as Gosling) has something to say about yield() in both the Language Specification, and his book, "The Java Programming Language". (actually, yield isn't specifically mentioned in the spec, but priorities and scheduling *are*.) And so when *I* am writing code, I use that as my guide, and to very roughly paraphrase, "yield sucks because it's behavior is not guaranteed or portable." and "for that matter, thread priorities aren't truly guaranteed either".
In other words, a thread that yields might just rudely jump right back to the front of the line, and in fact be the thread that goes right back in, so even though a thread yields, it does NOT guarantee that he will truly allow another thread to become the running thread.
And what about the whole priority thing? Gosling has something to say in the Language Spec about that. In general, a VM scheduler will *prefer* a thread of a higher priority over a thread of a lower priority, but there is no guarantee even of THAT.
Bottom line: no guarantees about yield doing ANYTHING, even in the face of threads of same or in some cases (i.e. some VMs) higher priorities.
And no *guarantees* about thread priorities. This does not mean that in practice, and on most VMs on most platforms, it doesn't work somewhat predictably, but it does mean NO GUARANTEE.
I emphasize "no guarantee" because if I were studying for the exam, I would be very very careful to understand what is and is not absolutely guaranteed by the language specification (or Gosling in any context), regardless of any results you actually achieve (or that anyone else recommends).
The point of the exam is to verify that you truly know how to guarantee that your code is portable.
Same deal with the Developer exam... if the assessor sees that your code, while running fine on the test machines, is relying on non-guaranteed behavior, then there's a big problem.
So back to when *I* write code, I don't rely on the behavior of yield() or priority-tweaking to ensure that my program will behave appropriately.
cheers,
Kathy
p.s. Dan, I am just barely beginning to look at your stuff, and it looks pretty impressive!! I'll have more to say later, but I'm happy about all of us making distinctions between mock exams that are for learning and mock exams that are for assessing readiness for the real thing. Both are extremely valuable.
And while I'm here, I promise most of my posts won't be this long. But no guarantee...
 
Dan Chisholm
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kathy,
Thank you for your response. Your input is extremely helpful and reassuring. My assumption has been that the influence of thread priority on the Thread.yield method is not guaranteed.
Yes, I would appreciate any feedback that you might have concerning my mock exam. An appropriate name for my web site might be Sun Certified Java Programmer Practice Exercises. However, I doubt that anybody is typing that search string into Google so I instead used the more popular "Mock Exam" title.
Thank you again!
 
Kathy Sierra
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, you can thank me by heading over to that topic, "The one thing I wish I'd done..." and posting something! Come on, it's my very first topic after all.
 
Dan Chisholm
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kathy,
I would be very happy to do that except from one small problem: I don't satisfy the requirement of being a member of the group of "people who've taken the exam". I have been developing my exam in preparation for taking the exam myself. After developing a large collection of practice programs, I decided to make them available to others that could use some additional practice. The early part of the exam contained only questions based on working programs. By using the "working program format" for all of the questions the answers were all guaranteed to be correct except in the rare instance of a careless mistake.
A second motivation for developing my exam was a desire to get some practice with XML and XSLT. The exam content is developed in XML format. JDOM is used to organize the various exam sets and number the questions and answers. XSLT is used to translate the result to HTML.
The development of the exam has been a great learning experience for me both in terms of Java and XML.
If I had to offer an example of one thing that I wish I had included in my exam but have not it would probably be your example--anonymous classes. I'll probably go back and develop some questions in that area soon.
I should also admit that I took some of your advice in another thread when I went back to the collections topic to develop some questions on LinkedHashMap and LinkedHashSet. I'll be uploading those to the beta section before long. You've only been back a few days and you're already having an impact!
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a nice theory about yield. It puts the thread in the Runnable-NotRunning (Ready) state again. Now the differences among the shedulers account for all the previously seen interpretations:
a) it yields only to threads of the same priority
b) it yields to threads of the same or higher priority. Shouldn't be due to the fact that a preemptive algorithm is able to replace a running thread with a one of a higher priority at ANY TIME?
c) there is no guarantee if it yields at all because it could be selected by the scheduler again.
d) another thread with a lower priority could be selected to avoid starvation --not receiving CPU time at all. But again this could happen at any moment, not only when yielding.
For the exam I think option a is safer.
I would use yield to avoid starvation in an application where all the threads has the same priority. Some systems would choose one of threads and would execute it untill, well, it yields or ends with it.
[ October 13, 2002: Message edited by: Jose Botella ]
[ October 13, 2002: Message edited by: Jose Botella ]
[ October 13, 2002: Message edited by: Jose Botella ]
 
Dan Chisholm
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jose,
You've made some great points, but--as Kathy pointed out--there are no guarantees concerning the behavior of Thread.yield.
I think the key point to her reply is contained in the following quote.


I emphasize "no guarantee" because if I were studying for the exam, I would be very, very careful to understand what is and is not absolutely guaranteed by the language specification (or Gosling in any context), regardless of any results you actually achieve (or that anyone else recommends).
The point of the exam is to verify that you truly know how to guarantee that your code is portable.
Same deal with the Developer exam... if the assessor sees that your code, while running fine on the test machines, is relying on non-guaranteed behavior, then there's a big problem.


I think I'll update the beta version of my Thread exam so that it further emphasizes the differences between guaranteed and non-guaranteed behavior.
BTW, thank you for your suggestions in the "Feed the Pets" thread. I greatly appreciate your help.
 
Kathy Sierra
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jose Botella:

<snipped>
a) it yields only to threads of the same priority
For the exam I think option a is safer.
I would use yield to avoid starvation in an application where all the threads has the same priority. Some systems would choose one of threads and would execute it untill, well, it yields or ends with it.


I think option 'a' is safe as far as knowing what is the stated behavior. And as long as you know that it does not mean that it actually WILL allow another thread of the same priority to run.
That said, yield should not be used to avoid starvation, regardless of priorities. Gosling says that yield() should be used only for potential efficiency, but *not* for algorithm correctness. Consider sleep(), join(), or wait() as the methods that will guarantee a thread backs out of running. (well, assuming you sleep long enough! try a short enough sleep duration on some VM's, and the same thread can actually fall asleep, wake back up, and become running again before another of your user threads is chosen! )
Again, the exam expects you to understand the difference between a guarantee and a "that's the way it works", and I also think yield() is probably the most subtle for making that distinction, since the API does say it causes a thread to allow other threads a chance. But the spec does not make any guarantees with respect to priority and scheduling, so it's not guaranteed to do much of anything, *reliably*.
cheers,
Kathy
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Kathy, no to use yield to avoid starvation, I will remember that.
________________________________________________
Dan, for evaluating what is it might be matter of the exam or not, the guaranteed-against-not-guaranteed approach has a serious drawback. In some situations there is a fine line between them, especially for someone taking the exam it can be difficult to discern some "advanced-delicate" issues. Example: this post. I prefer to rely on a judgment on what can be expected to be known by someone taking the exam. Though this can seem equally blurred, sometimes I have been judging a given question to exceed what should be known for the exam. Some guides could be:
a)Remember what we knew at the time of taking the exam.
b) Some level of knowlegde "well stablished", known to be sufficient for the exam but not difficult, as The Java Tutorial, relevant parts of the API, or Thinking in Java (just an axample).
 
Dan Chisholm
Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jose,
Thank you for the advice. I have not yet done any further work on the Thread exam so I will certainly keep your suggestions in mind when I do.
 
reply
    Bookmark Topic Watch Topic
  • New Topic