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

Re: Some questions about Ozone

On Wed, 09 May 2001, Daniel Weinreb wrote:
> Falko Braeutigam wrote:>
> 
> > > I also don't understand how recovery works on the name table.  What if
> > > there is a system crash in the middle of commitNameTable?
> > then the name table file is corrupt which forces the server to recover the name
> > table from the clusters on the next start up.
> 
> Oh, yes, I see.  Thanks.>
> 
> > > I don't understand how the beginExclusive(), commitExclusive(), and
> > > checkExclusion() mechanism work.  If a method M calls
> > > checkExclusion(), and some other thread is inside a
> > > begin/commitExclusive(), then it will wait; that's fine.  But as soon
> > > as checkExclusion is done waiting and checkExclusion returns to M,
> > > some other thread might enter a beginExclusive() again, before the
> > > rest of method M is executed.
> > Hmmm... maybe I don't fully understand the question.
> >
> > begin/end/checkExclusion() implements a simple semaphore. It allows to make
> > sure that a specified code block (not method) is executed by 0 or 1 thread only
> > at one time. The problem with semaphores is that check/set must be a atomar
> > operation - which is the case for the ozone code. (at least as far as I can see
> > ;) So where do you see a problem?
> 
> Sorry, I guess I didn't explain very well.  Let me try again.
> Suppose there are two threads executing called A and B,
> and they just happen to execute in such a way that their
> execution interleaves as follows:
> 
> A: call method Transaction.createObject.
> A: call env.transactionManager.checkExclusion()
> A: return from checkExclusion()
> B: call TransactionManger.checkDeadlocks
> B: call beginExclusion()
> A: continue executing createObject()
> 
> Now A is executing in createObject even though B is in between
> a beginExclusion and an endExclusion.  So I don't see what good
> it did to call checkExclusion().

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?


> > > In Object2XML: Do you really think it's safe to use
> > > System.identityHashCode to generate ID numbers?  These ID numbers
> > > ought to be unique, but two distinct objects can have the same
> > > identity hash code.  The usual design pattern that I've seen in such
> > > cases is to use a hash table to record the binding between objects and
> > > id numbers.
> > My JDK doc says that "the hashCode method defined by class Object does return
> > distinct integers for distinct objects" and identityHashCode() "Returns the same
> > hashcode for the given object as would be returned by the default method
> > hashCode()"... This is exactly what we need in the Object2XML code. Do I miss
> > something?
> 
> Really?  
Yes...

> The Javadoc that I'm looking at for Object.hashCode says:
> 
> It is not required that if two objects are unequal according to the
> equals(java.lang.Object) method,
>           then calling the hashCode method on each of the two objects must produce
> distinct integer results. However,
>           the programmer should be aware that producing distinct integer results for
> unequal objects may improve the
>           performance of hashtables.
... right below this section ;) which deals with the contract of
hashCode() in general, not the Object.hashCode() implementation. Anyway, ...

> 
> I'm pretty sure that, like any hash code, it is possible for two distinct
> values to hash to the same hash code.  
> There are certainly strategies
> for implemeting Java in which there would be no collisions, but there
> are also perfectly useful and legitimate strategies that would sometimes
> result in collisions.  I don't know which Java implementations out there
> actually can produce collisions and which cannot.

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


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