Bob Stone

I made mistake, the alternative should be :

Public void lockRecord(long recNo) throws RecordNotFoundException { long lockCookie = bookManager.lockRecord(recNo); if (data.readRecord(recNo) == null) { try { bookManager.unlockRecord(recNo); } catch (SecurityException) { throw new RecordNotFoundException("Cookie held by another client...."); } throw new RecordNotFoundException(...); } return lockCookie; }

Hi Randchers,

I�ve finished my B&S coding, and now I am doing Data.class testing for updateRecord() and deleteRecord(), but found the lockRecord method is not thread�safe. Here are the codes:
Public void lockRecord(long recNo) throws RecordNotFoundException { long lockCookie = -1 if (data.readRecord(recNo) == null) { throw new RecordNotFoundException(...); } else { try { lockCookie = bookManager.lockRecord(recNo); } catch (InterrupedException) { .... } } return lockCookie; }
where data is an instance of Data.class and bookManager is to logically lock (place an entry in a WeakHashMap) a record which prior to deleting or updating.
When multiple threads, delete and update together, acquire same record, a delete thread can lock a record that has been deleted. Say:
a delete thread and a update thread both can find the same record, now the update thread go asleep and the delete record carries on and finally removes the record. Afterward, a update record wakes up and then successfully locks up an unexisting record.

To fix it, an alternative is to lock record first regardless of it's existence. Here is the method
Public void lockRecord(long recNo) throws RecordNotFoundException { long lockCookie = bookManager.lockRecord(recNo); if (data.readRecord(recNo) == null) { throw new RecordNotFoundException(...); } else { try { bookManager.unlockRecord(recNo); } catch (SecurityException) { throws new RecordNotFoundException("Cookie held by another client...."); } } return lockCookie; }
Is it odd to handle securityException exception by rethrow a RecordNotFoundException exception with "Cookie held by another..." ? Or other solutions can anyone draw my attention?

Thanks very much

please forgive me once

Thanks Peter,

I've checked with some books in which specify that a thread gives up the CPU resource and the lock on a shared object if it encountered a wait() call in the object. So the question left is how can I use reentrantReadWriteLock().writeLock() to do the same thing as done by sychronized block and wait() call? Once again, many thanks for your reply.


Bob

typo - should be share object.wait().

Hi all,

I am writing an API that is required to be thread-safe. As I know if a share object is enclosed by a sychronized block, any attempt to lock the object that is already locked will be blocked. My questions are i.) is it using thread.wait() to cause those threads giving up the CPU resource? ii.) If using reentrantreadWriteLock().writeLock() instead of synchronized block, how to let those blocked threads giving up CPU time?


Thanks in advance

bob

Hi all,

I got the answer, how silly I am!

If the readers does not need to acquire a read lock before reading up, they can access the object while another thread is updating the object that will not maintain data integrity. Oh, I eventually understand why the concurrent API doc said read-lock can improve performance.

Thanks Gabriel,

I am getting clear about the ReentrantLock / ReentrantReadriteLock but another question has arised in my brain.
Is it necessary to acquire a read-lock for reading in the content of a shared object? Assume that a shared object is visible to some reader threads and one writer thread, the writer thread can update the shared object if it successfully acquires a write-lock, and reader thread is allowed to access the object without having to acquire a read-lock; if so, can the reader threads retrieve up-to-date content?

Thanks for you help.

Hi,
I am studying the mechanism of readLock() and writeLock() but is still hazy on them even read through the java.util.concurrent.locks API doc many times. I have encountered the following questions:

1. As I know the writeLock() is actually holding up a lock whereas readLock() doesn't; so why not simply using synchronized instead of readLock() if only implementing a thread-safe block? I brought Andrew's SCJD exam with J2SE 5 book in which the codes of DvdFileAccess.java :-

public DVD getDvd(String upc) throws IOException { ... recordNumbersLock.readLock().lock() try { ... } finally { recordNumbersLock.readLock().unlock() }

would it be simpler if using sychronized() block ?

2. Extend the above question, can a write thread place a lock on a share object while a reader thread has already held up a lock on the object and is processing some operations within the readLock block?

3. Can I say that the main purpose of readLock, other than polled, timed, and interruptible lock acquisition, is to guarantee memory visibility?

4. Is there any pre-defined preferences for readLock() or writeLock() acquisition?

I would be appreciated if I can have your input; if possible, could you suggest any material for my further reading?

Thanks in advance


Bob

Thanks all,
I will keep my design as simple so easily to be implemented and tested.

Hi all,
I am preparing the B&S project, and encountering the understanding of locking, as the requirement specified that:

[I]Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.[/I]

If just let the current thread keep waiting until the target record is released, it may be blocked very long time as the user holding the target record probably leaves for a day and then be back to continue record updating (what the one to do is so simply just to press the confirm button).
So I prefer to add a timestamp to the record reservation entry in which there are record no, owner Id (cookie), timestamp. If a (logical) locked record is pending more than 2 mins (time out), another thread to acquire the record will grant the right to lock it. This design can also serve the issue of client crashes.

But the requirement said that SHOULD cause the current thread to give up the CPU...., now my question is can I use the time out approach or not ?

Thanks
[ May 19, 2007: Message edited by: Barry Gaunt ]

go web page and download the source