Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Documenting Thread Starvation

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
from
http://www.coderanch.com/t/185099/java-developer-SCJD/certification/Thread-states-notify-notifyAll-wait
Max's (out of context) quote:

With the notifyAll call, the priority of the Threads(!=Max) will gradually get bumped until they
get a chance to run. Thus, you don't run the risk of starvation. Additionally, you're working
'within' the Threading system, priority and all. Finally, when a single Thread is concerned,
you don't get any sort of measurable performance hit either way. You're basically getting a
more extendable, scalable, and resilient implemention at no extra cost. Why wouldn't you
do it?

1. I take it Max is suggesting that you don't get this "for free" if you call notify() instead of
notifyAll()?
2. I take it that Max's above assertion is false (as he suggests) if the priority of the threads
is at the maximum.
Thus, not even the above idea is in and of itself safe. So, it should be documented, I assume.
Question:
If I use notify() in my LockManager (instead of notifyAll()) methods, and every incoming client
thread is normal priority, is it possible that a thread would starve indefinitely into the
future? And, is it something that is very improbable? And, of course, whatever is the truth,
I must document it so that clients don't abuse the system.
Question (rephrased):
To be 100% certain on all systems that a thread doesn't starve indefinitely into the future,
I must use notifyAll(), even if the "logic" of the coding indicates that a notify() would be
sufficient? [Of couse, this assumes that clients are not abusing the system by sending
in threads at the highest priority].
Thanks,
Javini Javono
[ February 22, 2004: Message edited by: Javini Javono ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
It is normally polite to include a link back to the thread you quoted from, so that people can see it in context.
From memory we did discuss this issue in that thread.
The issue with thread starvation can be separate from the issue of thread priorities. Threads that are in wait state will not have their priorities changed (regardless of whether you use notify() or notifyAll()).
This means that if you always have at least two threads in wait state on a single mutex, and you are using only the notify() call, then it is possible that one thread may never be woken up - it will starve.
But if you use notifyAll() then all threads that are in wait state will be transitioned to blocked state (temporarily) and while in blocked state their priorities may be increased over time giving them a greater chance of running next time they go into blocked state.
1. I take it Max is suggesting that you don't get this "for free" if you call notify() instead of
notifyAll()?

You wont get the same effect if you use notify() instead of notifyAll(). The concept of "for free" does not really apply if you are talking about using notify() instead of notifyAll() - it only applies if you are talking about using notifyAll() instead of notify().

2. I take it that Max's above assertion is false (as he suggests) if the priority of the threads
is at the maximum.

Part of the assertion would be false (the bit about priorities being increased), but the rest holds true. But you shouldn't be creating multiple threads with maximum priority anyway - certainly not for this task.

If I use notify() in my LockManager (instead of notifyAll()) methods, and every incoming client
thread is normal priority, is it possible that a thread would starve indefinitely into the
future?

It is possible if you always have two or more threads waiting on the one mutex.

And, is it something that is very improbable?

That depends on what your mutex is, and what your expected number of clients doing bookings is.
If your mutex is on the individual record itself (and you are doing one of the new (hotel or contractors) assignments) then it should be unlikely that starvation will occur.
But if your mutex is on the collection of locks, and you expect to always have at least two connected clients locking records simultaneously, the it is possible.

And, of course, whatever is the truth,
I must document it so that clients don't abuse the system.

I agree that you should document it.
But it is a bit harsh to say that clients have to avoid abusing the system - this problem could occur anytime you consistently have two or more clients performing locking simultaneously. This might not happen until they have connected 1000 clients to your system (which you might declare as abuse) but it could also happen if they had only 20 fast workers attached to the system - 1 of them could find their thread starving.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic