• Post Reply Bookmark Topic Watch Topic
  • New Topic

ReentrantReadWriteLock: static or not - variables to be locked: static or not  RSS feed

 
Sebastian Krings
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am going to enable multithreading to an existing program.
I want to use ReentrantReadWriteLock and some points but I think my question could be generalized to any locking mechanism.

Q1)
I have a big class with most business logic.
In my mind I have two alternatives how to make multithreading:
1) create some thread and assign them all the same reference to the big class
2) implement runnable to the bigclass and make itself being a thread
-> I am not sure whether this matters, because I think in 2) they also would gain the same reference to the big class as in 1), so it were equivalent, wernt it?


Q2)
Many samples for ReentrantReadWriteLock declare the instance of ReentrantReadWriteLock private (and sometimes final) but most times not static.
Well, the difference is as far as I know:
a) when the lock is static then all threads which are accessing the class where the lock is declared (in my case the big class) will "listen" to this lock (means when one thread locked, all others have to wait)
b) when the lock is not static then all thread which are accessing the class where the lock is declared (again the big class) will "listen" to only the lock of the instance of the big class (means when there is only one object of my big class an all thread refer to this, its equivalent to a) but when each thread gets its own instance of the big class the lock will not have any effect)

am I right here?


Q3)
I case of yes:
When we assume b) and additional there were some static variables then using non static locking would not take any effect (means although there is some (non static) locking the static variables are not synchronized).
Am I right or am I missing something?


Q4)
In many tutorials I found statements like: "if you want to allow acces to an variable over multiple thread use static variables so all threads can access them together and share data to each other"
When again we assume b) and all thread have a reference to the same object containing simple public non static variables. Wouldnt they also be suitable to share data over all threads?
If yes statements like above are just a little bit missleading in that way they then often sound like its the only way to share data.


Thanks in advance for response to my four topics/ questions.
 
Tim Halloran
Greenhorn
Posts: 5
Android C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sebastian Krings wrote:
Q1)
I have a big class with most business logic.
In my mind I have two alternatives how to make multithreading:
1) create some thread and assign them all the same reference to the big class
2) implement runnable to the bigclass and make itself being a thread
-> I am not sure whether this matters, because I think in 2) they also would gain the same reference to the big class as in 1), so it were equivalent, wernt it?


For 1) you need to make "bigclass" thread safe with regard to concurrent access (perhaps with locking, etc.). If you go with 2) then it might be that "bigclass" is thread confined and could use a non-lock concurrency policy.

It is a good idea to think of the policy you want -- shared, thread confined -- then consider the mechanism (locking, an executor)

Sebastian Krings wrote:
Q2)
Many samples for ReentrantReadWriteLock declare the instance of ReentrantReadWriteLock private (and sometimes final) but most times not static.
Well, the difference is as far as I know:
a) when the lock is static then all threads which are accessing the class where the lock is declared (in my case the big class) will "listen" to this lock (means when one thread locked, all others have to wait)
b) when the lock is not static then all thread which are accessing the class where the lock is declared (again the big class) will "listen" to only the lock of the instance of the big class (means when there is only one object of my big class an all thread refer to this, its equivalent to a) but when each thread gets its own instance of the big class the lock will not have any effect)

am I right here?


Static means all instances get the same lock, non-static means one lock per instance. Again, both approaches are valid in practice, however, you have to think in terms of what state the lock is protecting. In general (all else being equal) use a static lock to protect static state, and an instance lock to protect instance state.

Sebastian Krings wrote:
Q3)
I case of yes:
When we assume b) and additional there were some static variables then using non static locking would not take any effect (means although there is some (non static) locking the static variables are not synchronized).
Am I right or am I missing something?


I think so:-) If you protect static state with an instance lock and there is more than one instance then (and if the static state is shared) then the policy can exibit a race condition at runtime -- you need to protect the state with the same lock every time you access the state (not use multiple locks).

Sebastian Krings wrote:
Q4)
In many tutorials I found statements like: "if you want to allow acces to an variable over multiple thread use static variables so all threads can access them together and share data to each other"
When again we assume b) and all thread have a reference to the same object containing simple public non static variables. Wouldnt they also be suitable to share data over all threads?
If yes statements like above are just a little bit missleading in that way they then often sound like its the only way to share data.


If state is shared and it isn't immutable some mechanism is needed to ensure that updates become visible between the threads in your program. Perhaps take a look at the book Java Concurrency In Practice (Goetz et al.) and also the surelogic tools Flashlight and JSure (which you can get for free). JSure has a tutorial on ReadWriteLocks and can verify annotations introduced in the Java Concurrency In Practice book (I work on these tools, but they are helpful especially getting ReadWriteLock policies correct in code). Good luck with your project!
 
Sebastian Krings
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Halloran wrote:2) then it might be that "bigclass" is thread confined and could use a non-lock concurrency policy.


and if not? then its like 1?
interesting hint with the policy

Tim Halloran wrote:
Static means all instances get the same lock, non-static means one lock per instance. Again, both approaches are valid in practice, however, you have to think in terms of what state the lock is protecting. In general (all else being equal) use a static lock to protect static state, and an instance lock to protect instance state.


Its not about that they are valid, I rather would know where the difference is and if it can be equivalend (in case of not going the way of the other policy you mentioned).
So the crux is on " non-static means one lock per instance". This sounds like I expected it to be.
If all thread have the same reference ob the business object than having non static locks behaves like having static locks.
It then only differs when using another policy or not using the same reference for every thread.

Thanks for your reply.
I will get further into it.
 
Henry Wong
author
Sheriff
Posts: 22863
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

A couple of points ...

Sebastian Krings wrote:
So the crux is on " non-static means one lock per instance". This sounds like I expected it to be.


One. Be careful with this conclusion. Locks are objects -- and should not be counted by their references.

Yes. Non-static means one lock reference per instance -- but that may not be one lock per instance. All of, or many of, the lock references may point to the same lock object. You will need to examine the source code to determine if there is lock dependency between the threads.


Two. This topic is discussing to the ReentrantReadWriteLock class, which is different than the ReentrantLock class. The ReentrantReadWriteLock class implements a reader writer lock, and with that lock, it is possible for more than one thread to own the lock.

Henry
 
Sebastian Krings
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,


thanks henry, but I think I was still aware of this.
With "one lock per instance" I meant to have one "= new reentrantreadwritelock()" per instance of bigClass.
Of course I can use this reference of reentrantreadwritelock multiple times within code.

And yes I am talking about reentrantreadwritelock since I want to get its advantages of enabling concurrent reads but get its safe when doing writes.


So thanks. All in all now I think I have a right understanding of the topic (as far as we wrote about it here) because you answered my questions (that I were right) mostly with yes.
Thanks again.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!