Locking with java.util.concurrent

[Eiji Seki]

Hi,

I just noticed that my locking solution will not use much of the java.util.concurrent package. Is it strange? Is someone implementing in JDK 1.5 and using some important class of that package?

The only one I am planning to use right now is ConcurrentMap.

Another one interesting is the Lock interface and the ReentrantLock class. I'm thinking about using it's lock() method for record locking. Is it appropriate?

Should I study more about the features the package provides? Any advices on this?

Thanks

[Ronald Wouters]

Hi Eiji,

my LockManager class makes use of ReentrantLock instead of synchronizing directly on my lockedRecords map. It also uses Conditions (java.util.concurrent.locks package)to control threads waiting for a given record. My implementation (URLyBird 1.3.3) doesn't make use of ConcurrentMap.

Regards, Ronald.

[Eiji Seki]

Thanks, Ronald, I'll take a deeper look.

[Eiji Seki]

Sorry, Ronald, I did not understand what is the use of Condition. If I understood correctly, it is kind of an extesion of the Object wait and notify methods. With it we can have separate waiting groups and notify only the objects in one of them.

But since I am just controlling access to record writing, I see no need for that. Even if I was doing read and write locks, them should not I just use the ReentrantReadWriteLock?

I now undertood your implementation and where you are using Lock. I'm planning a different aproach: using an ConcurrentMap to store Lock objects, one for each record (together with the client ID). Is it too strange? Since I never worked with this concurrent package, I'm not sure how it works, but as fas as I read I think this solution is possible.

BTW, I'm also working on URLyBird 1.3.3.

[Ronald Wouters]

Eiji,

With it we can have separate waiting groups and notify only the objects in one of them

Exactly, I have one Condition instance for each record that has threads trying to use it.

But since I am just controlling access to record writing...

I use the Lock and Condition objects to control logical locking, meaning which user is trying to access which record. To control record writing I synchronize directly on my RandomAccessFile instance.

... should not I just use the ReentrantReadWriteLock?

I used ReentrantLock because it has the newCondition() method to generate the Condition instances that I use for logical locking/thread handling.

I'm planning a different aproach: using an ConcurrentMap

I just had a look at the API docs for ConcurrentMap, looks very interesting.

... store Lock objects, one for each record

As I mentioned above I use just one Lock instance, and multiple Conditions.
I have finished my locking stuff and working on the GUI now. Don't think I will revisit my locking, it drove me crazy working on it , lost a lot of sleep

Regards, Ronald.
[ March 23, 2006: Message edited by: Ronald Wouters ]

[Eiji Seki]

No need for you to go back .
Your solution looks very consistent, so I will think about using Condition or Lock for each record. Thanks a lot.

[Sergey Zolotaryov]

[B&S] I used a HashMap to store the locks, key is the recNo and value is a Cookie object. It stores the cookie value, a Condition object, which is used to notify record waiters (as there may be multiple waiters), and the number of waiters (this is added every time someone is going to wait for the record and deduced every time when a waiter has grabbed the lock). When the waiters number reaches zero the next time the record is unlocked, the Cookie and recNo is removed from the map.

[Mihai Radulescu]

Hi people

I just add my two cents here.
I don't think that its really count if you use a 100% 5.0 or not(the same is if you use RMI or not), what really count is a good/functional design.
A good design can be easy extended -the old parts(using 1.4 features) can be easy replaced with new the features (from 1.5).
My lock manager is based on "old" features and I don't think that will affect my grades.

Regards, Mihai

[Sergey Zolotaryov]

Yep, but concurrent library does relief you of the burden of testing your locking code. Everything is so easy with this package, that there is no need to reinvent the wheel.

[Mihai Radulescu]

Hi Sergey,

this is true you don't need to "reinvent the wheel" but you must be shore that you need a whell(and you really know how the wheel works).

Regards,
Mihai

[Eiji Seki]

So that's one of the many things you may learn taking the Developer exam.
Add a couple of wheels to your portfolio.