Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9801 > unrolled thread

Can you use "synchronized" for data members

Back to article view | Back to comp.lang.java.programmer

Contents

  Can you use "synchronized" for data members Nagrik <vnagrik@gmail.com> - 2011-11-09 10:32 -0800
    Re: Can you use "synchronized" for data members markspace <-@.> - 2011-11-09 10:40 -0800
      Re: Can you use "synchronized" for data members Tom Anderson <twic@urchin.earth.li> - 2011-11-09 22:02 +0000
        Re: Can you use "synchronized" for data members Patricia Shanahan <pats@acm.org> - 2011-11-09 14:07 -0800
      Re: Can you use "synchronized" for data members Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-09 17:09 -0800

#9801 — Can you use "synchronized" for data members

Hello Group,

Can the "synchronized" kew word be used in front of data members.  I
am aware that it can be used in fron of methods, and a block.
Something like this.

public class myclass {

synchronized prinvate int counter;  // Is it allowed

}

If the answer is yes then in what situation it is adviseable.

Thanks in advance..

nagrik

[toc] | [next] | [standalone]

#9802

On 11/9/2011 10:32 AM, Nagrik wrote:
> Hello Group,
>
> Can the "synchronized" kew word be used in front of data members.


No.  Use "volatile" for that.

[toc] | [prev] | [next] | [standalone]

#9804

On Wed, 9 Nov 2011, markspace wrote:

> On 11/9/2011 10:32 AM, Nagrik wrote:
>
>> Can the "synchronized" kew word be used in front of data members.
>
> No.  Use "volatile" for that.

Yes. Although it isn't *quite* the same thing.

By which i mean that:

class Smeagol {
 	private volatile int x;
 	public int getX() {
 		return x;
 	}
 	public void setX(int x) {
 		this.x = x;
 	}
}

And:

class Deagol {
 	private int x;
 	public synchronized int getX() {
 		return x;
 	}
 	public synchronized void setX(int x) {
 		this.x = x;
 	}
}

Have slightly different semantics. If thread A calls getX, and then thread 
B calls setX, then with Deagol, there is a happens-before relationship 
between the two calls. With Smeagol, there is not. Whereas if A calls setX 
and then B calls getX, both Smeagol and Deagol will generate a 
happens-before relationship.

Or so i believe. I hope someone will correct me if i'm wrong.

The good news is that in most cases, the weaker guarantees provided by 
Smeagol's volatile are actually just what you want (because you don't care 
that a write to a variable happens after a read), and the JVM can generate 
a more streamlined sequence of instructions for it.

tom

-- 
Eight-bit is forever

[toc] | [prev] | [next] | [standalone]

#9806

On 11/9/2011 2:02 PM, Tom Anderson wrote:
> On Wed, 9 Nov 2011, markspace wrote:
>
>> On 11/9/2011 10:32 AM, Nagrik wrote:
>>
>>> Can the "synchronized" kew word be used in front of data members.
>>
>> No. Use "volatile" for that.
>
> Yes. Although it isn't *quite* the same thing.
>
> By which i mean that:
>
> class Smeagol {
> private volatile int x;
> public int getX() {
> return x;
> }
> public void setX(int x) {
> this.x = x;
> }
> }
>
> And:
>
> class Deagol {
> private int x;
> public synchronized int getX() {
> return x;
> }
> public synchronized void setX(int x) {
> this.x = x;
> }
> }
>
> Have slightly different semantics. If thread A calls getX, and then
> thread B calls setX, then with Deagol, there is a happens-before
> relationship between the two calls. With Smeagol, there is not. Whereas
> if A calls setX and then B calls getX, both Smeagol and Deagol will
> generate a happens-before relationship.
>
> Or so i believe. I hope someone will correct me if i'm wrong.
>
> The good news is that in most cases, the weaker guarantees provided by
> Smeagol's volatile are actually just what you want (because you don't
> care that a write to a variable happens after a read), and the JVM can
> generate a more streamlined sequence of instructions for it.

Very often, for int, you need a much stronger guarantee. Consider
"x++;". It involves two memory accesses, one to read the old value of x
and the other to write the new value. If two or more threads are doing
similar operations at the same time, something has to be done to prevent
the following sort of thing:

x is initially 0
Thread A reads x, getting 0.
Thread B reads x, getting 0.
Thread A writes 1 to x.
Thread B writes 1 to x.

Two threads have each executed x++, but x has only increased in value by 1.

In many cases, AtomicInteger is a better choice than int for a variable
that needs to be operated on by multiple threads.

Patricia

[toc] | [prev] | [next] | [standalone]

#9807

On Nov 9, 10:40 am, markspace <-@.> wrote:
> On 11/9/2011 10:32 AM, Nagrik wrote:
>
> > Hello Group,
>
> > Can the "synchronized" kew word be used in front of data members.
>
> No.  Use "volatile" for that.

Oh goodness no. He's trying to make a simple int counter. Volatile
won't give atomic incrementing. He needs to have a synchronized block,
something like:
    synchronized (someObject) {
        ++counter;
    }
(Or something else fancier from the concurrent packages maybe (?) if
you're super concerned about speed and measurement says it helps.)

As a precaution, note that it will not work if you change counter to
Integer and synchronize on that, because Integers are immutable which
means different threads will be synchronizing on different objects
which doesn't give you the guarantees you need.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web