• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

synchronizing a block of code

 
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What exactly does the line
synchronized (letter)
do for me in this code??? I'm a bit confused by this.
-Dale
 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi..
In this code "letter" is acting as a monitor object to the block. Any thread wanting to access the block which it is guarding will have to ask him for the access and if any other thread is still running within the guarded block, the second thread would be made to wait just outside the block.
Regards,
Mehul K. Sanghvi.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some more thoughts...
I guess this code wants to illustrate why you might need to use a synchronized block, rather than simple synchronized methods. In this case, one single "letter" object is shared between all three threads and you need to coordinate access to it in some way. A synchronized method wouldn't work as each InSync object has its own monitor lock.
Whenever I see a synchronized block, my knee-jerk reaction is to check whether the code contained inside the synchronized block actually should be part of the object you're synchronizing on. In this example, though, you couldn't move the code into (a subclass of) it even if you'd want to - StringBuffer is final.
- Peter
 
Mehul Sanghvi
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Peter den Haan
bartender
Member # 862

Whenever I see a synchronized block, my knee-jerk reaction is to check whether the code contained inside the synchronized block actually should be part of the object you're synchronizing on. In this example, though, you couldn't move the code into (a subclass of) it even if you'd want to - StringBuffer is final.
- Peter

Could you please make me understand the importance of having the code in the monitor object itself... e.g.: collections objects are used as monitors for their own synchronized blocks etc..
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Mehul Sanghvi:
Could you please make me understand the importance of having the code in the monitor object itself...

It isn't always important. But a synchronized block can be a "code smell" that warrants investigation. A block that synchronizes on an object X usually contains some operation on X. Assuming this block is sitting in another class Y it may be that it is in fact more tightly coupled with X than with Y. If that is so it probably wants to be refactored into X.
Don't get me wrong. I'm not saying that this is always the case, just that it is worth checking for.
By the way, synchronized blocks are also often used in fine-grained synchronization, where an operation is split into multiple small synchronized sub-operations in an attempt to improve the concurrency of the code. Even then I would want to check whether the synchronized block can't be a separate (synchronized, private) method, as the code inside a block often represents a single, well-defined, discrete step and turning it into a method may clarify the code.
- Peter
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But aren't there some benefits from using sync. blocks such as reducing the size of the critical section? Also you can use different objects to sync. on, e.g. Peter Haggar's book has examples where he has:
byte[] x = new byte[0];
...
public void somefunc() {
...
synchronized(x) {
...
}
...
}
I thought these were rather interesting.
 
Mehul Sanghvi
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey guys,
Thanks.. I has helped me to look at it in a different angle.
Thanks again.
Regards,
Mehul K. Sanghvi.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jim Baiter:
But aren't there some benefits from using sync. blocks such as reducing the size of the critical section?

Not compared to the very same chunk of code sitting in a method

Also you can use different objects to sync. on

Absolutely. A couple of classes in the JFC use a monitor object, a new Object() created simply for its monitor lock. Take a look at java.io.File for example. Synchronized blocks are also necessary in other cases, e.g. an iteration over a (threadsafe) Collection must generally be synchronized on the Collection.
- Peter
 
Mehul Sanghvi
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

originally posted by Peter Hann Den
Not compared to the very same chunk of code sitting in a method


How would the same piece of code make a difference as to where it is place i.e within a method or as a seperate method having both of them synchronized?
Thanks in Advance.
Regards,
Mehul K. Sanghvi.
 
Mehul Sanghvi
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry Peter, for goofing up while writing your name.. :roll:
As though we Indians are good at First Names..!!

Regards,
Mehul K. Sanghvi.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry if I confused you. What I meant to say is that you don't necessarily need synchronized blocks to reduce the size of the critical section. A synchronized blockhas no benefits whatsoever overTo the contrary, the latter form is often more readable as "foobar" is usually a single well-defined concept. In general, code that outlines an algorithm in high-level method calls is much easier to read and maintain than code that goes into implementation details straightaway.
It's not always easy or obvious to do this, though, specifically if there are multiple temporary variables being used. At the same time multiple temporary variables in a complicated method can make the code hard to understand, in which case it's worthwhile to see if things can be broken up or otherwise simplified.
- Peter
PS. Don't worry about my name you should see the indigities it had to suffer at the hands of the British since I hopped across the channel!
[ February 15, 2002: Message edited by: Peter den Haan ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic