Threading

[Tomasz Wilk]

Hi All,
I finished writting my application, I started to check it out... and I dont like my threading.
First I wanted to use synchronized + wait and notify. There should be waiting on map of cookies and on seperate value later on. However I read much about locks and I love idea of having ReentrantReadWriteLock.
For every created row I have a lock (just reentrant one). So every row can be locked separately which doesn't stops other threads from working on different rows. My lock() looks like this:
public long lock(int id) {
//I use mainLock to lock create operation as atomic one (I threat it as //write operation)
Lock readLock = mainLock.readLock();
readLock.lock();
Lock lock = null;
synchronized (this) {
lock = locks.get(id);
if (lock == null) {
lock = new ReentrantLock();
locks.put(id, lock);
}
}
lock.lock();
long cookie = generateCookie();
synchronized (cookies) {
cookies.put(id, cookie);
}
return cookie;
}

The problem for me is a create/delete method as they change number of rows... I guess it is not a problem for reading and finding - in worst case scenario some rows will just not be read. But for writting it is a problem because we can overwrite previous value... My delete doesn't phisically delete a row (it only marks it as not available).

So finally, what do you think about such concept? Could you name a book I coud use to polish my threads knowledge?

[John Stone]

One of the rancher "Henry Wong" is author of: "Java Threads"
I've not read it, so I can't give you any comments, try to check thread for books. Also you can find some comments in FAQ.

http://www.amazon.com/Java-Threads-Scott-Oaks/dp/0596007825/ref=pd_bbs_sr_1/105-5771735-5123659?ie=UTF8&s=books&qid=1184493051&sr=8-1
[ July 15, 2007: Message edited by: John Stone ]

[rinke hoekstra]

Hi Tomasz

The ability to lock every record separately with its own ReentrantLock object is very nice and I would certainly apply it to a real world application, but it is not needed for this assignment.


I would opt for the most simple approach. Any deviation from that won't gain you extra points, and more complicated code can only cost you extra points.

[Tomasz Wilk]

well, yeah, but the method signature is lock(int recNo) - I would understand that the single record is to be locked, not all of them...

[rinke hoekstra]

Originally posted by Tomasz Wilk:
well, yeah, but the method signature is lock(int recNo) - I would understand that the single record is to be locked, not all of them...

Yes, but I think you are mixing two things up, when saying that.
First of all, you have the logical record locking, that's what the lock method is doing: it tells your app: "don't touch this rec now, as someone is busy with it".

Then there is the locking in the sense of synchronization, which happens on the datafile and on the HashMap which keeps your locks, and it is done because changing operations on them must be atomic. Locks on this are something completely different, and the time of such a lock is usually very short.

Now the lock method you are talking about is the "logical locking", which happens on the rec level (you lock one rec). However, this does not mean that your synchronization is obliged on the record level too. It is perfectly ok to synchronize the whole HashMap while putting an item in it. OK, this method is a bit "rough" but very simple, and as the time of these kinds of locks is very small, it is no problem.