Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

"static" and threads explanation?

 
Tommy Sedin
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I hope this question landed in the right part of this forum.
I've read on a few sites that you should always try to avoid declaring methods and/or variables as static when several threads will try to access them (I think the actual words were "avoid static like the plague"). Now, I understand what happens when you declare a method or variable as static, but I'm not sure exactly how it affects threading.
I'm guessing that you cannot call static methods simultaneously, but reading static variables in non-static methods should have no such limitation.
That would explain the use of "factory methods" that I see a little here and there..
So the question is basically: How does declaring methods and variables as static affect Java's ability to access these methods and variables from different threads simultaneously?
Thanks for any help
Tommy Sedin
 
boyet silverio
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just imagine, that in a video-music bar, a mike (microphone) while being used (threading/processing) by a customer is suddenly held also by another who had too much to drink during the new year's party and started garbling a different tune (thread/process) at the same time. It would probably be bedlam if the current holder refuses to give in! This situation could arise if the mike is "static", that is, the mike could just be used by any customer anytime.
public class Customer{
static String mike;
public void setSong(String song)
{ mike = song; }
public String getSong()
{ return mike; }
}
say, in the video bar, customer # 1 merrily sings "Jingle bells! Jingle bells!" (in thread 1)
i.e. customer1.setSong("Jingle bells! Jingle bells! Jingle all the way! ...");

then another customer (#2) joins in and simultaneously sings (in thread 2)
i.e. customer2.setSong("We will, we will rock you! chug-chug-chug, chug-chug-chug! ...");
when customer # 1 tries to listen to the speaker boxes,
i.e. customer1.getSong();
instead of hearing his voice, he might be hearing the angry voice of customer # 2's ... "we will we will rock you....."
i.e. return mike
n.b. thread ~ process
I hope this helps, in a way.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Calling a static method from different threads is similar to calling a non-static method on the same object from different threads. As long is it does only work on local variables, it can't do any harm at all - and if it does work on fields, you'd need to think about synchronization, anyway.
So I don't see how wether to make a method static should be influenced by threading issues.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, if you're calling a static method in a multithreaded environment, there's a good chance the method is synchronized. This means that all threads will be synchronizing using the same monitor - namely the Class object representing the class in which the static method is defined. This may well create a single choke point in the application, as each thread has to wait for access to that monitor before it can proceed. If the method is nonstatic rather than static, then there's a greater chance that different thread will be attempting to synchronize on different monitors, and thus will not compete directly for locks. But this really depends on how you distribute and use the objects containing synchronized methods - it's difficult to make many general statements here.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic