0

If I have a an object with an attribute private int i;, I know I can make the getter and setter methods "synchronized" like so ... But since it's possible another method might be added later that accesses/changes i directly, is there any way to declare that i is a "synchronized" attribute?

public class SharedObject {

  int i;

  synchronized public int getI() {
    return i;
  }

  synchronized public void setI(int i) {
    this.i = i;
  }

  public void badMethod() { <<-- added at later date by forgetful programmer
    // accidentally messes up 'i' because method is not "synchronized" !!
  }

}

I thought maybe this could work, but it didn't:

public class SharedObject {

  synchronized int i; <<-- this won't compile

  public int getI() {
    return i;
  }

  public void setI(int i) {
    this.i = i;
  }

  public void badMethod() {
    // cannot mess up 'i', because 'i' is declared as 'synchronized'
  }

}
  • There's [`volatile`](http://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html), but whether or not that's "equivalent" to you depends on exactly what you're trying to achieve. What concurrency problem(s) are you aiming to solve? – Matt Ball Apr 23 '14 at 00:17
  • You could use Atomic reference types. – Mark W Apr 23 '14 at 00:20
  • @MattBall Just trying to understand threading better. I was asked in a job interview "if you should put a synchronized block around a boolean attribute", and I didn't know -- I said 'yes', but he said it wasn't necessary because changing the boolean value is an atomic action. So I'm wondering if there is a way to 'synchronize' the attribute other than making the getters/setters synchronized. When he said 'putting a synchronized block' around the boolean, did he mean "synching" the getters and setters? –  Apr 23 '14 at 00:22
  • 1
    I don't think putting `synchronized` on the getter and setter will achieve too much - they won't help you in any case where you'd need `AtomicInteger`. I also think that the interviewer is mistaken - a line like `setFoo( ! getFoo())` where `Foo` is boolean is certainly not atomic, and nor is `foo = ! foo` from inside the class. – Dawood ibn Kareem Apr 23 '14 at 00:26
  • @DavidWallace Thanks, if I remember his exact words, he said, "When you have a boolean attribute in an object accessed by several threads, do you have to put it in an synchronized block?" Still not sure what he meant by a "synchronized block" in this context. –  Apr 23 '14 at 00:28
  • Sounds like a poorly/vaguely stated question. If I were asked that question I would ask the interviewer some questions of my own, to clarify. – Matt Ball Apr 23 '14 at 00:29
  • 1
    I wouldn't. I'd explain to him what `synchronized` blocks do, and what `volatile` means, and let him see from that (a) that the question is meaningless, and (b) that I understand this stuff better than he does. – Dawood ibn Kareem Apr 23 '14 at 00:31
  • @MattBall Thanks -- the thing is, I'm weak on multi-threading, so in a job interview situation it was difficult to know if I would be asking a stupid question or not. :) –  Apr 23 '14 at 00:31
  • @DavidWallace Thanks for the help, too late now, but my effort here is to learn multi-threading better so I'll be better equipped to answer such questions in the future. –  Apr 23 '14 at 00:33
  • Just FYI, it was an interview at a major silicon valley company -- list the five biggest companies you can think of, it was one of them -- I have to think he was asking a legitimate question. Who knows, maybe it was a trick question to see if I'd challenge him on it like David suggests. –  Apr 23 '14 at 00:34
  • Maybe. I'm not above tossing out poorly worded questions in job interviews to see how the candidate will react. – Dawood ibn Kareem Apr 23 '14 at 00:37
  • Typically when you encounter this kind of vague question, the interviewer expect you to ask clarifying question. Like "is the boolean final", if it is you don't need any synchronization. Also, FYI, according to JLS, primitive operation is atomic (with some exceptions). http://stackoverflow.com/questions/1006655/are-java-primitive-ints-atomic-by-design-or-by-accident – Alvin Apr 23 '14 at 01:12

1 Answers1

0

There is no way to declare a member variable as synchronized.

However, if i represents independent state of the object -- in other words if i can be set and get independently of other state and you're not depending on the synchronization of the getter and setter of i to serialize access with other synchronized methods, then you can declare i as volatile.

You could consider moving all concurrency-critical code to its own class (and even declare the class final) which might perhaps make the intent more clear. But if a "forgetful programmer" can make changes to the source code, there is nothing to prevent any sort of error from being introduced.

Chuck Batson
  • 2,165
  • 1
  • 17
  • 15