wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes MulitLock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "MulitLock" Watch "MulitLock" New topic
Author

MulitLock

Andreas Hollmann
Greenhorn

Joined: Jan 06, 2010
Posts: 27
Hi,
Have any body heard about method to lock many variables at ones? it could be a possibility to write code without deadlocks ...

For example:
Ashish R Garg
Greenhorn

Joined: Jan 15, 2009
Posts: 8

As far as I know, Synchronized block accepts only an object as a parameter.
Secondly, why would you want to do that, I mean separating Read and Write locks doesnt make any sense.
Let me quote from Effective Java - Joshua Block: Chapter 10- Concurrency

It is not sufficient to synchronize only the write
method! In fact, synchronization has no effect unless both read and write
operations are synchronized.


So I would suggest that if you wish to synchronize all three variables, better wrap them in an object, or make an object variable for locking them.

Intrinsic Locks and Synchronisation

While we are at it, I suggest you to go through Concurrency framework for its Lock interface and relevant implementations.

Happy Ranching!


Never settle for less. Never Quit.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Andreas Hollmann wrote:Hi,
Have any body heard about method to lock many variables at ones? it could be a possibility to write code without deadlocks ...

For example:


Unless that syntax it new in Java 7 (I'm almost certain it's not) or being discussed for Java 8 (I doubt it) then no, you can't do it that way.

However, you can obtain multiple locks simply by nesting synchronized blocks. And there are Lock classes in java.util.concurrent that distinguish read locks from write locks.

Note, however, that none of that does anything to prevent deadlock. Deadlock occurs when two or more threads try to acquire two or more exclusive resources in different orders. Thread 1 obtains lock A and then lock B, while thread t2 obtains lock B and then lock A. Regardless of which technique you use to obtain multiple locks, if you don't do it in the same order, you risk deadlock.
Andreas Hollmann
Greenhorn

Joined: Jan 06, 2010
Posts: 27
Thank you for your replies,
Last time I wrote a lot multi-threaded code by using fine grained locking. My code became very complex, failure became not reproducible -> regression tests became to the last hope to find such bugs :-)

I want to be able to start synchronize block where I define required resources and don’t care about deadlocks. Therefor I started to develop a little framework for multi-locking. The framework should schedule the execution of synchronization-blocks thus deadlocks will be avoided. I'm exiceted to see how it will be working.

Secondly, why would you want to do that, I mean separating Read and Write locks doesnt make any sense.

ReadLocks are important and I have many cases whre the performace can be dramaticlly improved. Please have a look at ReadWriteLock JDK1.5:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html

Best Regards
Andreas Hollmann
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

Andreas Hollmann wrote:
Secondly, why would you want to do that, I mean separating Read and Write locks doesnt make any sense.

ReadLocks are important and I have many cases whre the performace can be dramaticlly improved. Please have a look at ReadWriteLock JDK1.5:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReadWriteLock.html


I think you are mis-interpreting the response. The quote from Joshua Block (via Ashish R Garg) is trying to say that the same locks should be used for both read and writes. Or more likely, but hard to tell, as there isn't enough context, that the programmer shouldn't forget to lock the read operation, just because that thread isn't changing anything.

As for reader writer locks, I can argue that it is the same lock. True. It looks like two locks, as it is two different objects. However, it is really the same resource, it just happens to have different modes of operations that allow the lock to allow parallel operations under certain conditions.


Also, be careful not to abuse reader writer locks. Let's not forget that synchronization, especially when it is uncontended, is incredibly efficient. If the application is not bottle-necking on the locks (either there isn't enough lock grabs, the lock ownership period is very short, or there is plenty of time for those locks to interlace), the reader writer lock may not have any (or very little) benefits.

Henry

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18978
    
  40

Andreas Hollmann wrote:
I want to be able to start synchronize block where I define required resources and don’t care about deadlocks. Therefor I started to develop a little framework for multi-locking. The framework should schedule the execution of synchronization-blocks thus deadlocks will be avoided. I'm exiceted to see how it will be working.


As Jeff already mentioned, one common way to avoid deadlocks is to establish a lock order -- meaning you enforce an order that states, to own a lock later on the list, you need to own all the earlier locks on the list, even though those locks may not be needed. Let's say that the list is A B C, then to own lock C, you need to grab lock A and B first, even though it doesn't look like you need it. It is a bit weird, and it does make fine grain locks more coarse, but it does help with deadlocks when there are complex lock interactions going on. And obviously, don't have one big list -- it is silly to put completely unrelated locks together.


Anyway, to answer your question though. The Lock class does have the option to try out a lock -- meaning only acquire it if it is not owned. So, with this feature, you can write a framework that will try out all the locks, and if any of them fails, then release them all, wait a tad (or wait on a condition), and then try again.

Henry
Andreas Hollmann
Greenhorn

Joined: Jan 06, 2010
Posts: 27
Thank you for your reply,

I think you are mis-interpreting the response. The quote from Joshua Block (via Ashish R Garg) is trying to say that the same locks should be used for both read and writes. Or more likely, but hard to tell, as there isn't enough context, that the programmer shouldn't forget to lock the read operation, just because that thread isn't changing anything.


You are right that is a big chalenge to develop multi-threaded code and I think it is time for creating of new tools! In the future the wrong ussage of Read-Locks will produce comple-errors.

the reader writer lock may not have any (or very little) benefits.

I think MultiLock with combination of read & Write locks can became new paradigm for developing of MultiThreaded code and hopfully will replace such tools like Barrier, CounDown Latch.
In constrast to actual cuncurrent tools the MultiLock-technology will not allow deadlocks to be produced.

I hope to release MultiLock tools in next release of Happy Java libraries.

For example currentlly this code works fine:



Best Regards
Andreas Hollmann
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Do you have a question, or are you just promoting your library?
Andreas Hollmann
Greenhorn

Joined: Jan 06, 2010
Posts: 27
Do you have a question, or are you just promoting your library?

:-D

I hoped there is a tool which can synchronize many variables, thus I'm not implementing a dublicate.

Yes I need your help! I'm still not sure about API:
1) Are names of classes and methods compressive?
2) Which features are importent for you?

I whould be glad about any ideas how such MultiLocks can or should work ....
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: MulitLock