Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Synchronized access

Reply
Thread Tools

Synchronized access

 
 
Stanimir Stamenkov
Guest
Posts: n/a
 
      04-13-2004
I've read statements that using a separate object to lock on, rather
than using a synchronized method, to synchronize an operation on
other object is better, i.e.:

public class Pencho {

private int mField;

private Object mLock = new Object();

public int makeSomething(int pNumber) {
syncrhonized (mLock) {
mFiled = (mField + pMagicNumber) / 2;
return mField;
}
}
}

and:

public class Pencho {

private int mField;

public synchronized int makeSomething(int pNumber) {
mFiled = (mField + pMagicNumber) / 2;
return mField;
}
}

Is there benefit of using the first approach over the second one
(and specifically for the above simple example)?

--
Stanimir
 
Reply With Quote
 
 
 
 
Paul Bilnoski
Guest
Posts: n/a
 
      04-13-2004
> I've read statements that using a separate object to lock on, rather
> than using a synchronized method, to synchronize an operation on
> other object is better, i.e.:
>
> public class Pencho {
>
> private int mField;
>
> private Object mLock = new Object();
>
> public int makeSomething(int pNumber) {
> syncrhonized (mLock) {
> mFiled = (mField + pMagicNumber) / 2;
> return mField;
> }
> }
> }
>
> and:
>
> public class Pencho {
>
> private int mField;
>
> public synchronized int makeSomething(int pNumber) {
> mFiled = (mField + pMagicNumber) / 2;
> return mField;
> }
> }
>
> Is there benefit of using the first approach over the second one
> (and specifically for the above simple example)?
>

I believe there isn't a difference between placing all the code in the
method within an extra 'synchronized (this)' block. The synchronized block
lets you localize the critical section of code. If the entire method is the
critical section, then it's a (slight) convenience to just tag the entire
method with a mutex.

> --
> Stanimir


--Paul


 
Reply With Quote
 
 
 
 
Tony Morris
Guest
Posts: n/a
 
      04-14-2004

"Paul Bilnoski" <(E-Mail Removed)> wrote in message
news:c5hqvh$sf0$(E-Mail Removed)...
> > I've read statements that using a separate object to lock on, rather
> > than using a synchronized method, to synchronize an operation on
> > other object is better, i.e.:
> >
> > public class Pencho {
> >
> > private int mField;
> >
> > private Object mLock = new Object();
> >
> > public int makeSomething(int pNumber) {
> > syncrhonized (mLock) {
> > mFiled = (mField + pMagicNumber) / 2;
> > return mField;
> > }
> > }
> > }
> >
> > and:
> >
> > public class Pencho {
> >
> > private int mField;
> >
> > public synchronized int makeSomething(int pNumber) {
> > mFiled = (mField + pMagicNumber) / 2;
> > return mField;
> > }
> > }
> >
> > Is there benefit of using the first approach over the second one
> > (and specifically for the above simple example)?
> >

> I believe there isn't a difference between placing all the code in the
> method within an extra 'synchronized (this)' block. The synchronized block
> lets you localize the critical section of code. If the entire method is

the
> critical section, then it's a (slight) convenience to just tag the entire
> method with a mutex.
>
> > --
> > Stanimir

>
> --Paul
>
>


There is a HUGE difference between the two posted examples.
One might argue that:
synchronized void m(){}
is equivalent to
void m(){synchronized(this){}}
however, this is not entirely correct - and there is a significant
performance benefit gained from taking the former approach.

Is is extremely important to recognise that the two posted examples do not
make this comparison - the lock (aka monitor) is not a reference to 'this',
which causes a VERY BIG functional difference - a difference which I won't
explain in details since it is already well covered elsewhere.

"to synchronize an operation on other object is better, i.e.:"
I assume you mean "to synchronize an operation on an object that is not
'this' is better", in which case, this is entirely incorrect and quite
often, the contrary is true (that synchronizing on anything but 'this' is
bad practice).
There is a benefit gained by synching on an internal object, however, as
this is improving encapsulation i.e. you aren't exposing your object monitor
(i.e. all other references that are == to 'this').
If you don't understand some of these fundamental practices, I would suggest
you follow the less problematic (loosely speaking) approach of synchronizing
only on a 'this' reference.

For further information:
http://java.sun.com/docs/books/tutor...ads/index.html
"Taming Java Threads", Allen Holub

Note: Usually I wouldn't give such a detailed explanation, but I can't
resist when I see blatant false advice being handed out.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform


 
Reply With Quote
 
Stanimir Stamenkov
Guest
Posts: n/a
 
      04-14-2004
/Tony Morris/:

> "to synchronize an operation on other object is better, i.e.:"
> I assume you mean "to synchronize an operation on an object that is not
> 'this' is better", in which case, this is entirely incorrect and quite
> often, the contrary is true (that synchronizing on anything but 'this' is
> bad practice).
> There is a benefit gained by synching on an internal object, however, as
> this is improving encapsulation i.e. you aren't exposing your object monitor
> (i.e. all other references that are == to 'this').
> If you don't understand some of these fundamental practices, I would suggest
> you follow the less problematic (loosely speaking) approach of synchronizing
> only on a 'this' reference.


I understand my example uses two different approaches to synchronize
operation on a 'Pencho' type of object (it modifies some of its
member fields). While in the first case the operation locks on an
internal object (other than 'this Pencho') the second locks on 'this
Pencho' itself.

I think my question was clear enough, but I was more interested if
there's any benefit in the performance. If your answer is: "There is
a benefit gained by synching on an internal object, however, as this
is improving encapsulation i.e. you aren't exposing your object
monitor (i.e. all other references that are == to 'this')." - o.k.,
but your other writings just confuse me.

> Note: Usually I wouldn't give such a detailed explanation, but I can't
> resist when I see blatant false advice being handed out.


Thank you for the effort.

Best Regards,
--
Stanimir
 
Reply With Quote
 
=?ISO-8859-1?Q?Daniel_Sj=F6blom?=
Guest
Posts: n/a
 
      04-14-2004
Tony Morris wrote:
> There is a HUGE difference between the two posted examples.
> One might argue that:
> synchronized void m(){}
> is equivalent to
> void m(){synchronized(this){}}
> however, this is not entirely correct - and there is a significant
> performance benefit gained from taking the former approach.


Tony is correct here, although by reading the java language
specification you might think otherwise. The relevant info can be found
in the JVM spec. Basically:

synchronized void m() {}

sets a flag for method m in the method table saying that the method is
synchronized. Handling the locks/unlocks is left to the VM.

void m() { synchronized(this) {}}

however, results in the compiler generating monitorenter/monitorexit
instructions in the method body. This includes an exception handler with
monitorexit at the end of the method, since locks must be released no
matter what happens.

So prefer the method synchronization over synchronized(this) since it
makes the code smaller, and the VM probably has some special tricks for
the former. Not that I'd expect this to make any significant difference
in practice.

> Is is extremely important to recognise that the two posted examples do not
> make this comparison - the lock (aka monitor) is not a reference to 'this',
> which causes a VERY BIG functional difference - a difference which I won't
> explain in details since it is already well covered elsewhere.
>
> "to synchronize an operation on other object is better, i.e.:"
> I assume you mean "to synchronize an operation on an object that is not
> 'this' is better", in which case, this is entirely incorrect and quite
> often, the contrary is true (that synchronizing on anything but 'this' is
> bad practice).


I agree.
--
Daniel Sj÷blom
Remove _NOSPAM to reply by mail

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Synchronized Block v.s. Synchronized Method Jerry Java 4 08-11-2010 02:34 PM
Question on synchronized and non synchronized methods ankur Java 4 11-28-2008 09:56 PM
Threads and synchronized access to an array Bob Bobrov Ruby 3 06-19-2008 10:54 AM
synchronized block in synchronized static method dmcreyno Java 9 06-27-2006 07:43 PM
Use of synchronized variables over synchronized methods? Pep Java 6 08-15-2005 01:29 PM



Advertisments