Hmmm, not quite sure that I get this all right, but to me it seems you
describe the simple read/write locks (without the upgrade step). Is
that possible? If so you could simply use the ReadWriteLockManager.
Oliver
On Thu, 31 Mar 2005 14:34:24 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> In the documentation I find that while an upgrade lock is held, it is possible
> for read locks to be obtained, and when the request is made to upgrade to a
> write lock, the lock manager prevents additional read locks until the write
> lock
> can be acquired.
>
> I don't understand why when the upgrade lock is granted, it is possible to
> obtain read locks ? Is there a reason to keep accepting read locks when you
> already know (because there is a upgrade lock on the data) that the data will
> be
> updated soon ?
>
> The behaviour that I want for my lock manager is following. To modify a data,
> you must obtain an upgrade lock if there is already read locks on the data and
> then to transform the upgrade lock in write lock when all the readers ended.
> When the upgrade lock is granted no more read locks could be granted.
>
> Is it possible to implements this behaviour using the
> ReadWriteUpgradeLockManager ?
>
> For the moment I implements the transformation of an upgrade lock in a write
> lock when all readers finished.
>
> public class LockManager
> {
> public static ReadWriteUpgradeLockManager mRWULockManager;
>
> public LockManager()
> {
> mRWULockManager = new ReadWriteUpgradeLockManager
> (new PrintWriterLogger(new PrintWriter(System.out), "Locking", false)
> , mRWULockManager.DEFAULT_TIMEOUT);
> }
>
> public static void readDemand(Thread aOwnerId, Interval1D aIntervalToLock)
> {
> mRWULockManager.readLock(aOwnerId, aIntervalToLock);
> }
>
> public static void writeDemand(Thread aOwnerId, Interval1D aIntervalToLock)
> {
> if(mRWULockManager.tryWriteLock(aOwnerId, aIntervalToLock) == false)
> {
> upgradeDemand(aIntervalToLock, aOwnerId);
> synchronized(aIntervalToLock)
> {
> try
>
> aIntervalToLock.wait();
> writeDemand(aOwnerId, aIntervalToLock);
> }
> catch (Exception e) {}
> }
> }
> }
>
> /**
> * Traitement d'une demande d'un lock Upgrade
> * @param aOwnerId Thread Identifiant du demandeur
> * @param aIntervalToLock Interval1D Intervalle à verrouiller
> */
> public static void upgradeDemand(Interval1D aIntervalToLock, Thread
> aOwnerId)
> {
> if(PDOM.TRACE)
> System.out.println("LM: Upgrade Demand");
> mRWULockManager.tryUpgradeLock(aOwnerId, aIntervalToLock);
> }
>
> /**
> * Relacher un lock
> * @param aIntervalToUnlock Interval1D
> * @param aOwnerId Thread
> */
> public static void release(Interval1D aIntervalToUnlock, Thread aOwnerId)
> {
> if(PDOM.TRACE)
> System.out.println("LM: Release " + aOwnerId + " " + aIntervalToUnlock);
> synchronized(aIntervalToUnlock)
> {
> mRWULockManager.release(aOwnerId, aIntervalToUnlock);
> aIntervalToUnlock.notifyAll();
> if(PDOM.TRACE)
> System.out.println("LM: ******** Il devrait repartir ********");
> }
> }
>
> In this sense the write lock becomes preferred over all other locks when it
> gets
> upgraded from a upgrade lock. Preferred means that if it has to wait and
> others
> wait as well it will be served before all other none preferred locking
> requests.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
