Grady wrote:

Here's the original implementation of the SimpleDB:

private boolean hasOtherSLocks(Block blk)
{ return getLockVal(blk) > 1; }

isn't that suppose to be >= instead of > 1?

I think you are right. However, although the current implementation seems to be wrong, it actually allows transactions like "r₁(x),w₁(x)" (i.e. lock upgrade) to work, so be careful if you change it.

HelloWorld wrote:

cysun wrote:

Grady wrote:

Here's the original implementation of the SimpleDB:

private boolean hasOtherSLocks(Block blk)
{ return getLockVal(blk) > 1; }

isn't that suppose to be >= instead of > 1?

I think you are right. However, although the current implementation seems to be wrong, it actually allows transactions like "r₁(x),w₁(x)" (i.e. lock upgrade) to work, so be careful if you change it.

In addition, I notice this:

 

   synchronized void xLock(Block blk) {

      try {

         long timestamp = System.currentTimeMillis();

         while (hasOtherSLocks(blk) && !waitingTooLong(timestamp))

            wait(MAX_TIME);

         if (hasOtherSLocks(blk))

            throw new LockAbortException();

         locks.put(blk, -1);

      }

      catch(InterruptedException e) {

         throw new LockAbortException();

      }

   }

in the current xLock implementation, it seems that it doesn't check if there's other Transaction that owns the Exclusive Lock? It just check if other transaction has the Shared Lock?

Yes, it looks like the current concurrency control implementation in SimpleDB is like place holders. So make any changes as you see fit.

In this implementation >1 means that there is more than one transaction that hold S-lock on this particular block. However, we cannot say if the caller of this method is within those S-lock holders.

Even in case of =1 it does not tell which transaction holds this S-lock.

OK, please ignore what I said. I read the SimpleDB code again and I think it does work. Please check out my explanation at http://sun.calstatela.edu/csns/forum/viewTopic.html?topicId=2118223.