> > 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.
Agreed, I see no liveness issues in those methods.
> >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.
I agree, Doug Lea's book is great. I did think about what I was doing,
although I admit relative inexperience.
Doug Lea quote 1: "Declare all public methods as synchronized: or if not,
describe the assumed invocation context and/or rationale for lack of
synchronization."
Doug Lea quote 2: "Do not require 100% conformance to rules of thumb..."
> Your best guard upfront to avoid the embarassement
> is to have the code reviewed by experienced programmers
Thanks. I guess I thought that was what I was doing, sorry if this is not
the right forum. But I did not just throw sync's in without thinking about
it, can you tell me where my mistakes are or what would be a better
approach? I'm never embarrassed when I can learn something.
Thanks,
Chris Campbell
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
