[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some questions about Ozone
Falko Braeutigam wrote:
> You are right, methods that already have called checkExclusion() are not
> blocked. However, the only alternative (which would run as fast as current code)
> that I found was to suspend/resume all threads. I didn't like that and
> suspend()/resume() are depricated anyway. Do you have a suggestion?
Sorry, no. I don't even completely understand what the existing rules
are for when the code needs to be inside "exclusion", i.e. what data
structures are being protected by it, etc. Detecting deadlocks while
various transactions are running around locking and unlocking things
is a hard problem. It's easier if you can define it to be OK to
occasionally give a deadlock exception to a thread that's not
actually in a deadlock.
... indeed there is a very (?) little chance that two hash codes out of
> identityHashCode() collide. My quote of the Java doc wasn't complete. The doc
> states that the hash codes are distinct "As much as is reasonably practical,..."
> Do you think this does not fit the needs of the Object2XML class? If so, do you
> have a suggestion how this could be improved?
But the "as much as as reasonably practical" is just a statement about what
you ought to consider likely; it's no guarantee. Identity-based hash codes
can be hard to do in the fact of copying GC's or other, fancier GC schemes.
What Object2XML is doing here is a design pattern that I've been familiar
with since over 20 years ago, when I worked on Lisp compilers that faced
the same issue of writing out a data structure and maintaining proper
object identity in the face of the object's being connected via an arbitrary
graph. You need to assign unique identifiers (usually integers) to every
object, so that if you see it again you can emit the integer instead of trying
to write out a second description of the same object. So to get the unique
ID numbers, you create a hash table whose key is any object and whose
value is an integer ID number, and you assign successive integer ID's to
objects that are referenced but not yet found in the table. Of course that's
more expensive than the identityHashCode since you end up with a hash
table that might get rather big. But have you ever heard the cynical saying that
"optimization is taking something that works properly, and making it work
faster and almost properly"? This is one of those cases.
-- Dan