This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

Simple question about Starvation

 
Alex Matute
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey!! Just a very quick question, suppose this kind of starvation:


Is it needed to implement a solution (time-based) for this cases or is it enough with documenting this in the locking contract in javadoc and the choices.txt?

BTW, my lock signature is:


and I'm implementing a thin client approach so Threads are ok as client id's for the locking mechanism.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12012
218
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alex,

Personally I don't believe it is necessary to handle this, however it is a good idea to mention in your choices documentation that you have considered it, and what your decision was.

Potentially more important than the lock method's signature is the comments for the lock method that Sun gave you. Is there anything in the comments that indicates that it might be reasonable for you to release a lock at some point in the future?

Regards, Andrew
 
Alex Matute
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thnx for answering Andrew! I've just re-read my instructions and they don't provide information in this aspect, they don't even insinuate anything, so I'll just document this situation in both: Data user's API (a warning in the Locking Contract) and choices.txt

Have a nice day!
[ August 14, 2005: Message edited by: Alex Matute ]
 
Jan Groth
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi alex,

starting my application, i thought about the same question as you. i decided to implement a WatchDog thread, which kills lock on a time-out base.

but there are a number of problems going with it:

- you need to find a reasonable standard configuration

- you need to provide a reasonable configuration possibility for the watchdog
(but also avoid the need for sun to manipulate any files by hand)

- killing a lock will lead to a whole bunch of new cases:

- say the lock-issueing thread (T) is not dead, just very very slow. what if you kill the lock in exactly the same moment when T writes to the database? or has just written to the db, simply not releasing the lock? another thread will immediatly aquire the lock and try to write himself... not good.


i'm almost finished with my application, but i'm short before replacing the watchdog witch something more stable in terms of db-consistency.

i'm very interested in any other opinions on this subject... Please share your thought with me.

thanks,
jan.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic