• Post Reply Bookmark Topic Watch Topic
  • New Topic

static, instance methods, Thread safe issue  RSS feed

 
Costa lamona
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

1- Instance data accessed only by synchronized instance methods.
2- Static data accessed only by synchronized static methods.

You have to respect this rules if you do not want to have a nasty bug.
but
what if I need to access static data by synchronized instance method or
the vise versa, I was told that there is a way to do that while the class can still thread safe, well What is it?
 
Costa lamona
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just forgot to say Thanks

so

Thanks
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe that is a question difficult to answer in a forum. And I am pretty sure that reading a couple of books on multithreading programming with Java will indeed help you master this concept.

I am far from being an expert, but I have read Mr. Henry Wong book (who by chance is an honorable member of the JavaRanch) and I would recommend it to you: Java Threads, 3rd Edition

I think that when you have a class member that can be modified by multiple threads concurrently, you have to synchronize access to your variables, regardless of the modification is happening in a static or a non-static context.

For instance, I could have a class that counts how many instance of it are created.



In this case the variable count could be incremented by multiple threads concurrently instantiating a new class Counter. How to synchronize access to the variable count from a non-static context?. As far as I understand, there are several mechanism to do that, all of them are approaches with different adventages and disadventages.

One alternative in this case is to declare the variable as volatile (but be careful volatile is not the cure of all evil). If you are using JDK 1.5 you could also use an atomic object (i.e AtomicInteger).

Another option could be to use a synchronized block to get a lock on the class.



Or you could declare a synchronized method for the increment operation:



Or if using JDK 1.5 you could also use the new Lock objects provided in the java.util.concurrent package.

And I am pretty sure there could even be other possibilities. Therefore, I believe there is not a single way to do it, and it all could depend on the particular problem you want to solve.
[ October 25, 2006: Message edited by: Edwin Dalorzo ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Mohammed]: what if I need to access static data by synchronized instance method or
the vise versa


If a single method (static or nonstatic) needs to access both static and nonstatic data, that can be a bit complicated. My first preference would be to see if you can refactor the methods of the class so that isn't necessary. But assuming it is necessary - can you separate the methods into two parts, such that all static access is in one part, and all nonstatic access is in another part? With no overlap? Then you can use two synchronized blocks to do what you need:

This same idea can also work with more than two static blocks - as long as the blocks don't need to overlap at all. If they do need to overlap, then you can nest sync blocks - but it's risky, as nesting sync blocks can lead to deadlock if you're not very careful. In this case, I would avoid deadlock by always syncing on the static part first:

That should be safe, as long as no other code ever locks in a different sequence. And note that I would really prefer not to lock on publicly-accessible monitors in the first place - because you never know what other threads may be doing with those same references. Instead I'd prefer to use a few privately-held references. Something like this:


That way you're more secure knowing who has access to your locks. Also this approach makes it easier to replace your synchronized blocks by using java.util.concurrent.locks.Lock instances instead of plain Objects, should you choose to do so. Which is not a bad idea, but it does give you more things to learn about, if you haven't already.
 
Lucas Lee
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It seems you had not get the right way.
If your instance if not in a multithreading environment,you have not to consider
the thread-safe problem.

For example,in servlet environment,one servlet instance maybe shared by multiple thread,then your servlet must be thread-safe.But your other instance of your classes,is not necessary if it is created and called in your serlvet method.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!