• Post Reply Bookmark Topic Watch Topic
  • New Topic

synchonize on boolean  RSS feed

 
Robert Kennedy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I have two classes and each running its own thread and sharing a boolean. Must I create a synchonized block (method) for a boolean?

Thanks
 
Rob Spoor
Sheriff
Posts: 20895
81
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't synchronize on primitive types, so if synchronization is required than perhaps it is better to make it a Boolean instead.
 
Robert Kennedy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

Thank you for your response.

If I share an int as a status value between two threads I do not need to wrap this int in a synchronized block for reading and writing but if I use I boolean I must wrap the shared boolean in a synchronize block.

Is this correct?

Thank you.
 
Robert Kennedy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also if my implementation is always a simple read or write to a shared boolean is a synchronized method sufficient? For other objects I have created a lock object to use for synchronization and this works well. However for a boolean it appears to be overkill.

Thanks!
 
Robert Kennedy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I read this article which appears to indicate that synchronization on an int is a good approach.

http://java.sun.com/docs/books/tutorial/essential/concurrency/syncmeth.html
 
Robert Kennedy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is this dangerous? I think it should be ok:

public void clickPause(){
setPause(!getPause());
}

synchronized boolean getPause(){
return bPause;
}

synchronized void setPause(boolean pause){
bPause=pause;
}
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Robert Kennedy:
Is this dangerous? I think it should be ok:


This is an excellent example of why synchronization is tricky. Your get/set methods are synchronized, and what this does is make sure that all threads involved will all see a consistent value for the variable. This is good.

But... the public clickPause() method is not synchronized. That means that multiple threads could call it at the same time, and that can lead to some surprising results. For example, calling clickPause() twice should result in bPause being toggled twice and ending up at its original value, right?

But imagine that two threads call it. Both threads read the old value of the flag, and both get the same answer. Then both set the flag to the opposite of that value -- the opposite of the original. Now one of the calls has "disappeared." Depending on your application, this could not matter, or it could be an enormous failure.

Either way, it's bad coding. If you're going to read and write a variable from multiple threads this way, then any chain of accesses like this should be synchronized, so that the chain can't be interrupted. Or you could use the java.util.concurrent.atomic.AtomicBoolean class, which has some methods that do test-and-set atomically (i.e., un-interruptibly.)
 
Robert Kennedy
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you!
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Rob]: You can't synchronize on primitive types, so if synchronization is required than perhaps it is better to make it a Boolean instead.

You mean like this?


I don't think that will work at all. If the Boolean is the mutable data that's being shared, then you can't effectively synchronize on that data. I mean, it's possible to write code that does this, but doing so will not protect the integrity of the data. Because the reference to the Boolean must be accessed by the sync block before you synchronize on it - the reference itself is accessed without synchronization. And if another thread comes along and tries to sync on myData after it's changed (but before the sync block has ended), it will probably sync on a different Boolean than the first thread. Which means that the two method calls can execute concurrently, and the sync block does not prevent this. Because the Boolean being used to control access is a mutable field. In short, this is not an effective way to protect access to myData.

Subsequent code here shows synchronization on the class that contains the boolean data, rather than on the Boolean itself. This is the standard approach, and will work much better - subject to EFH's comments about the problem with not synchronizing clickPause() as well. But if we fix that by synchronizing clickPause(), this will work fine. Other techniques are also possible, as EFH notes.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!