Re: Re: cdbd and fs2d_lock_node

Hmmmm...I see.  That makes sense, as during a write transaction, readers
won't notice the set of all changes until lock holder unlocks/commits
the transaction.  

Though, there's not much point to do a read_lock in the first place. 

Thanks for the info Paddy, I just wish SGI could release more internals
doc on the cdbd...it has a lot of potential:)

Kashif


On Mon, 2003-03-31 at 20:03, Padmanabhan Sreenivasan wrote:
> 
> CDB locking does not follow normal locking 
> semantics. It has optimistic concurrency controls 
> for read transactions (minimizes the duration
> of read-only operations blocking). So 
> CDB reader will get older version of the data
> if there is an update to the CDB node during
> the read transaction. CDB reader will also get
> an error and CDB reader can retry if they want.
> 
> Paddy
> 
> 
> Kashif Shaikh wrote:
> > 
> > I've been looking at the cdbd's transaction system, and some bits of
> > code are counter-intuitive to me.  I hope one of you or both of you can
> > answer some questions I have.
> > 
> > In the case of fs2_write_lock, this is the lock graph (assume blocking
> > locks):
> > 
> > NOLOCK := no lock
> > READ = read lock
> > WRITE := write lock
> > CP := Calling/Current FS2 Process (i.e. lock is held by current
> > transaction)
> > DP := Different FS2 Process(i.e. lock is held by different transaction)
> > NP1 := Arbitrary Node Pointer 1
> > NP2 := Arbitrary Node Pointer 2
> > 
> > Node Lock State   | Request Lock by CP | Lock Result
> > ---------------------------------------------
> > NOLOCK(NP1)       | WRITE(NP1)         | OK
> > WRITE (NP1) by CP | WRITE(NP2)         | OK, Lock upgrade.
> > READ  (NP1) by CP | WRITE(NP1)         | FAILED.
> > WRITE (NP1) by DP | WRITE(NP1)         | WAIT_FOR_LOCK(sleep)
> > READ  (NP1) by DP | WRITE(NP1)         | OK!!!???
> > 
> > When looking at the code, the last case should block as deemed by
> > fs2d_find_lock_conflict, but it doesn't in reality.  From my inspection,
> > when acquiring a read lock, the transaction is not binded to the NP.
> > This is a bug(I think it is)? Or has some sly unattended effect?
> > 
> > Now when we look at fs2_read_lock, I see some 'does not look right'
> > cases:
> > 
> > Node Lock State   | Request Lock by CP | Lock Result
> > ---------------------------------------------
> > NOLOCK(NP1)       | READ(NP1)          | OK
> > READ  (NP1) by CP | READ(NP2)          | OK, Lock upgrade.
> > WRITE (NP1) by CP | READ(NP1)          | OK, NO-OP, Keep lock as RW
> > READ  (NP1) by DP | READ(NP1)          | OK
> > WRITE (NP1) by DP | READ(NP1)          | OK!!!???
> > 
> > The last case is critical, though according to the code, I don't see any
> > lock conflict performed by current process's attempt to acquire a read
> > lock on a node that has been write locked by another process.
> > 
> > Why is this the case? Intuitively, I would expect the process to block,
> > but it doesn't! At the very least, it should fail.  Are there some
> > assumptions being made, for which I'm not aware of? Or are cdbd locking
> > semantics completely different from the norm?
> > 
> > Sorry for asking you two so many questions :)
> > 
> > Regards,
> > 
> > Kashif Shaikh
> 
> -- 
> Padmanabhan Sreenivasan (Paddy) 
> High Availability & Clustering 
> (650) 9336331
> _______________________________________________
> LinuxFailSafe mailing list
> [email protected]
> http://lists.community.tummy.com/mailman/listinfo/linuxfailsafe