Chris Kimpton <[EMAIL PROTECTED]> writes:
> Hi,
>
> > Any comments?
>
> Looks fine by me.
>
> My only thoughts/concerns was the sync'ing of getStale and isStale - would they lock
>each other out - as one calls the other - but I think Java threading handles that -
>and I guess you would hit this in your testing anyway.
>
No of course not. Your executing thread either holds the monitor for the
object or it does not. A typical deadlock situation occurs when thread A is
holding resource x and is waiting for resource y while thread B is holding
resource y and waiting for resource x.
>From this it obviously follows that your risk of deadlock increases with
the number of synchronizations you have. Depending on your application
deadlock may or may not be a more serious problem than invalid data
access. But in any case multithreaded code require careful thinking - just
throwing "synchronized" keywords in is not smart. I would rather recommend
starting with Doug Leas excellent book on concurrent programming in Java.
Also - it is often very hard to reproduce problems with multithreaded code
in testing, because you are relying on the execution order of the
statements. Often such problems only show up as "weird" cases after the
system has real users... Your best guard upfront to avoid the embarassement
is to have the code reviewed by experienced programmers(other than
yourself, because you tend to overlook your mistakes...)
regards,
Gunnar
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
