Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: Any possible way to guarantee no thread starvation?

 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I was thinking about trying to implement some sort of lock queue for my assignment, in order to prevent thread starvation. However I am now faced with a tough quandry:

Is then any way to guarantee, i.e. there 100% chance, that no thread will ever starve waiting for a lock. Even if using some sort of queue, won't threads wanting a place on this queue need to enter a synchronized block at some point to "add request for record lock".

Once threads are blocked, waiting for some objects monitor, I thought it was up to the mighty JVM to select which one can next get the objects monitor when it is free, and enter the synchronized block.

If there are many, many threads waiting for the monitor, and new threads starting to wait all the time, isn't it possible that some thread that the JVM "just doesn't like" will never get into that synchronized block?

Am I right? Am I confused? Any help would be... well... helpful.


Michal

[ September 05, 2004: Message edited by: Michal Charemza ]
[ September 05, 2004: Message edited by: Michal Charemza ]
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess it is possible, but do you care?
If a record is locked, a record is locked, you can have time outs for bad clients or with thin client you get just good clients.
If a thread is waiting, it is consuming no CPU cycles. So it is not behaving badly. Since you should always ues a separate thread to do those database calls, everything else can work just fine.

I guess the answer to your question is if you have thick client write your lock code so that it detects bad clients and gives up locks, if you have thin client - don't care
[ September 05, 2004: Message edited by: mike acre ]
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by mike acre:

I guess the answer to your question is if you have thick client write your lock code so that it detects bad clients and gives up locks, if you have thin client - don't care


Sorry I don't think I am explianing myself well: I don't think thin/thick clients have much to do with what I asking about.

Let me start again. Let's forget about record locking for the moment, and look at this block of code:



Let us assume that we have one thread in the middle of "veryLongOperation()", and many, many others waiting to enter the syncronized block. Also, new threads are being started all the time, all waiting to go into the synchronized block. So essentially, there will always be many threads waiting to get into the sychronized block.

A JVM is free to decide, in any way it chooses, which threads gets to go into the synchronized block. Therefore there is the possiblity that in the above senario, a JVM can decide to keep choosing certain threads, such that a thread will simply never get a chance to get into the synchronized block.

Is there any way to guarantee that this will not happen?

Michal
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you use notifyAll then all threads are woken and they keep trying to gain the lock on the objects monitor until one succeeds.
notify() does not do this, one is awoken and if it does not succeed then another notify call will be required before any others get a go.

This behaviour is guaranteed, as long as you implement it correctly.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Michal,

Originally posted by Michal Charemza:
If there are many, many threads waiting for the monitor, and new threads starting to wait all the time, isn't it possible that some thread that the JVM "just doesn't like" will never get into that synchronized block?


That is something you really don't have to worry about. There are some very, very complex algorithms that have been developed over the years which try to ensure that no thread ever starves. Sun do their best with this, and continue to optimise their code to ensure that no thread ever starves. You can develop your code with the assumption that they are getting it right.

Originally posted by Michal Charemza:



Hmmm, going to stop quoting you at this point, as this is (IMHO) going into a bad discussion. We are talking about handling something that is bad coding practice to begin with, rather than avoiding the bad practice.

We really do not want any long operations to be inside synchronized blocks - the blocks should only encapsulate the smallest amount of code which can possibly get the work done. And that is one of the major reasons for having the logical record locks - by using them effectively, the amount of code inside a synchronized block can be reduced to a few lines.

Reduce the size of the code in synchronized blocks, and you will improve concurrency, reduce the time taken to run the block and hence reduce any bottlenecks.

Regards, Andrew
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Monkhouse:

We really do not want any long operations to be inside synchronized blocks - the blocks should only encapsulate the smallest amount of code which can possibly get the work done.


Yes, I agree. I think I way just trying to make my point clearer with the veryLongOperation(). You can have a very short operation inside a synchronized block, but threads springing up at a tremendous rate to access it, and still a thread may never get its turn.

But technically, a JVM that completely 100% adheres to the JLS (or is it JVMS??), the above secanario can happen, and there is nothing that can be done to 100% guarantee that it will not happen? I know you can try to avoid it by, as you say, making code inside syncronized blocks as short as possible, but I mean guarantee that it won't.

I think maybe I am just remembering from the programmer's exam things like "When it comes to threads, very little is guaranteed" (S&B p493)

I think I just really don't like to write anything that I know has ways in which it can fail, especially if I know from the get go even before I write it. I understand the secario is highly, highly unlikely in this assignment (or any, for as you say the JVM really tries to avoid it) - but it's not impossible, and a JVM would still be adhereing to the JLS/JVMS by letting it happen.

Also, I suppose I am really taking heed of advice not to rely on any one particular JVM. Perhaps a bit too much heed. I think I almost have an idea of an "evil JVM", that takes advantage of every loose rule in the JLS/JVMS, and I still want my program to work on that, in as many senarios as possible.


Michal
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic