Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
  • 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Threading

 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
     
    author and jackaroo
    Posts: 12199
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
     
    I need a new interior decorator. This tiny ad just painted every room in my house purple.
    Free, earth friendly heat - from the CodeRanch trailboss
    https://www.kickstarter.com/projects/paulwheaton/free-heat
    reply
      Bookmark Topic Watch Topic
    • New Topic