• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Threading

 
Pieter Jacobs
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again,

1- In general I declare all my member variables "private" and then create public "getter" and "setter" methods to get and set the values respectively. Will I have to declare all these "getters" and "setters" "synchronized" (for threading) and the member variables "volatile" (so that the threads handle the variables correctly) ?

2- One of the reasons I'm asking is: from what I've read, synchronizing methods can decrease performance big time ?

Thanks,
Pieter
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Pieter,

Are you familiar with threading ? And what the purpose of the "synchronized" keyword is? It seems you don't really know what it's really about, so here are some pointers:
  • When to use "synchronized"
  • When to use synchronized or Lock / Condition objects?

  • I didn't use "volatile" throughout my application. All my public methods in the Data class are "synchronized", so my Data class is thread-safe. But as you pointed out in your last remark: this approach is not that performant, but this approach is very easy (no synchronization blocks you have to use etc.) and an easy approach is preferred to a more performant one.

    Kind regards,
    Roel
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12014
    220
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sometime prior to JDK 1.4 synchronization caused some pretty hefty performance loss. By the time of JDK 1.4 it was almost a non-issue. These days (and you can test this yourself) making something synchronized has so little effect on performance that you can effectively discount it.

    What can cause a performance hit is contention for resources. This issue is the same whether the resource in question is a synchronized block, accessing a single socket, using a single file descriptor, or placing all your SQL code inside transactions. If all clients are going to get blocked around a single resource then the application as a whole will suffer.

    Therefore whenever you make a distributed application you should consider how you can reduce contention for single objects. Ebay actually make a case for removing all transactions from their calls to the database. (!) In our case, it makes sense to reduce the synchronized code to the smallest logical blocks possible. You rarely need an entire method synchronized. The usual use-case I see is when somebody synchronizes the lock method. But even there it can make sense to synchronize on a different mutex rather than the Data class.

    One of the questions you should be asking yourself around about now is: exactly what do you have that could potentially be changing that you would need to make atomic? There should really only be one or two objects that are shared between clients that are variable. The object holding the locks is one. The file descriptor is potentially another. Any others?
     
    Pieter Jacobs
    Ranch Hand
    Posts: 88
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Roel (and Andrew),

    Thanks man, I really do appreciate your (and everyone else') feedback!

    You know what; I actually got myself so worked up after reading through loads and loads of these Topics on Friday night, that I started to feel quite intimidated by some of the guys' code snippets. I actually just stopped that for now, and is focusing on what I need to do and do it the way that I would do it - and of course ask the necessary questions as soon as I get stuck.

    Thanks, I have read through the information from the links you've provided!

    Enjoy the evening and speak to you soon.
    Cheers.
    Pieter
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic