[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some questions about Ozone

On Thu, 10 May 2001, Daniel Weinreb wrote:
> 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.

The exclusion methods are there to protect the object table and name table from
being read or modified while a transaction is commiting. So, it doesn't have to
much todo with the ordinary object locking and deadlock detection. Simply
synchronizing thw accesses to the tables is not a good idea here so I went
ahead and used thread priorities to let the commiting thread run exclusively.
This of course did not work on multiproc machines. So the next version used
suspend()/resume(). These methods are deprecated now (and not a good idea to
use anyway) so I came up with the current solution. As you pointed out this is
still a hack. A robust implementation of semaphores and monitors is needed,
which then can be used to model the behaviour that is needed in each particular
case. In case of the commit exclusion some kind of a multiple-reader-one-writer
semaphore would be the best solution. What do you think?

Daniel, it seems that you know much about concurrency problems and stuff like
that. Are you interested in helping with the development of a new and robust
basis that handles concurrency and related things in ozone?

> 
> ... 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, 
We did not use this approach because it assumes that hashCode()/equals() is
properly implemented for each and every object (primary _and_ secundary) in the
database and, even if it's properly implemented, you cannot tell anything about
the complexity of these operations. And, since database objects are not often
used as keys in a hashtable, they use the default implementation of
hashCode(), which return identityHashCode(), anyway.  Anyway...

> 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.

... you are right, although nobody reported problems with it, the current
version might not work in each and every case. But your idea introduces
problems too (see above) so what is a good solution?


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com