• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Question on using object's methods from multiple threads

 
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to know if I can keep the following method unsynchronized.

I have a class that has a method send(Message msg). This method calls many other methods on the same object, BUT every method it calls only uses the objects/variables passed in to them. For example, it might be like this:



So my question is, if I call "send( msg )" from many concurrent threads, will there be any problems? My initial thought is that there will not be since there's no variables that can be handled by multiple threads, but I am not 100% sure.

Can someone tell me if I'm ok thread-wise?

Also, should I make these methods static? Is there a reason to/not-to? Will there be a difference performance-wise?

Thanks!
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If none of these methods use member variables, and none of the argument objects are used in multiple threads, then no, nothing needs to be synchronized. The separate threads can proceed independently in that case.

Performance differences between static and non-static methods are miniscule, but the cost in flexibility and maintainability can be large. Never do anything because "it might be faster" unless you've got a performance problem, and even then, profile and work on the real problem. Don't guess.
 
Dan Bizman
Ranch Hand
Posts: 387
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks!

One question, you say, "the cost in flexibility and maintainability can be large." What then (for methods as I described them) do you feel is the more flexible/maintainable approach? making them static?
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Making them static is costly. If a method is static, then by necessity, the exact name of the class it appears in is scattered all over your application. If you someday decide that method needs to be polymorphic, or if you want to use a different implementation on certain platforms, or for debugging, etc, then you have to change code all over the place. If the method is non-static, though, then the name of the class can be much more localized, and the changes are easier to make. This is especially true if (as is always a good idea!) your functionality is represented by interfaces your service classes implement, and their clients are written to the interfaces instead of to the concrete classes themselves.

If you don't know what I'm talking about, our "OO, Patterns, UML, and Refactoring" forum is a good place to ask!
reply
    Bookmark Topic Watch Topic
  • New Topic