Oops,
yes you are right! this seems to be a bug.
Maybe Matthew knows more about this issue?
cheers,
Thomas
Steven Richman wrote:
> Yes, I saw that. I don't see how this prevents two threads from getting
> the write lock at the same time:
>
> /**
> * MBAIRD: We need to synchronize the get/put so we don't have two
> threads
> * competing to check if something is locked and double-locking
> it.
> */
> synchronized (locktable)
> {
> objectLocks = (ObjectLocks) locktable.get(oid.toString());
> if (objectLocks == null)
> {
> objectLocks = new ObjectLocks();
> locktable.put(oid.toString(), objectLocks);
> }
> }
> objectLocks.setWriter(writer);
> return true;
>
> So, if another thread has the lock, locktable.get will return the existing
> ObjectLocks object, objectLocks.setWriter will happily overwrite the
> writer member variable, and InMemoryLockMapImpl.setWriter will return
> true.
>
> ,steven.
>
> On Mon, 7 Jul 2003, Thomas Mahler wrote:
>
>
>>We are relying on Java synchronisation in setWriter:
>> /**
>> * MBAIRD: We need to synchronize the get/put so we don't have
>>two threads
>> * competing to check if something is locked and double-locking it.
>> */
>> synchronized (locktable)
>>...
>>
>>
>>
>>Steven Richman wrote:
>>
>>>Hi,
>>>
>>>I'm trying to understand some of the code in the odmg locking
>>>implementation.
>>>
>>>In all of the locking strategies, there is code like this:
>>>
>>> public boolean writeLock(TransactionImpl tx, Object obj)
>>> {
>>> LockEntry writer = getWriter(obj);
>>> if (writer == null)
>>> {
>>> if (setWriter(tx, obj))
>>> return true;
>>> else
>>> return writeLock(tx, obj);
>>> }
>>> ...
>>>
>>>(and similar code for read locks). Here, setWriter is
>>>AbstractLockStrategy.setWriter, which returns LockMap.setWriter. I'm using
>>>the InMemoryLockMapImpl, and if you look at the code for
>>>InMemoryLockMapImpl, setWriter *always* returns true.
>>>
>>>So, my question is, if the "if (writer == null)" test succeeds, but
>>>another thread acquires the lock before we call setWriter, isn't that bad?
>>>setWriter always returns true, so the call to writeLock will return true,
>>>and there will be two threads that think they have the lock at the same
>>>time. Or is there some higher level synchronization that I'm missing that
>>>keeps this from happening?
>>>
>>>thanks,
>>>steven.
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
|