• 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
  • Tim Cooke
  • Ron McLeod
  • paul wheaton
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
  • Himai Minh
Bartenders:

Synchronization

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Ranchers,

I've been stuck to understand below code (from K&B chapter 9 page 709) :



I know that synchronization is mechanism of controlling the access of shared resources by the multiple threads so only one thread can access a particular resource at a time.

in //1 -->it synchronized whole doStuff() method, so only one thread can access that method, the other threads cannot access it until the first thread exit the method, but I can't get what happened in //2. please help me to understand this concept.

Thank you
 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vierda,

in this case of your example it doesn't matter whether you use synchronized as a modifier for the method or if you use synchronized(this) in the method.

Both synchronize to the intrinsic lock every object in Java has. A synchronized method is just a short-hand for a synchronized block which spans the whole method body and uses "this" as its lock.

An advantage of case 2 is, that if you expand you method body later you don't easily forget that a synchronized block should be as small as possible to support good concurrency. By synchronizing the whole method there's of course no way to narrow the synchronized block.

Marco
 
Ranch Hand
Posts: 258
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
See, you can synchronize a method or block of code using this object.
What the code you have given does is its behavior will be same.
Thing is just that rather than having a lock on whole method you can
only lock the part of the method you want to make secure from the multiple
access.

What happens then is the part of the code that is not synchronized can get accessible to another thread and you can get more
benefit of the threading concept.

So just it is for getting more and more specific while locking avoiding unnecessary blocking


Regards,
Vijay Jamadade.
( I am JAVA +ve)
 
Vierda Mila
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Marco & Vijay,

thank you for your prompt reply.
But just want to confirmation below statement :


What happens then is the part of the code that is not synchronized can get accessible to another thread and you can get more
benefit of the threading concept.



is it mean that if I have rest code of doStuff() method, it can accesible to other threads and only the synchronized block that prevent the other threads to access it in same time??

appreciate for your clarification, thank you.
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To exploit better concurrency it's of course better not to synchronize because this blocks other threads to enter the synchronized block simultaneously.

On the other hand you have to use proper synchronization to avoid race conditions and support correct visibility of your data to all threads. So you usually try to synchronize a code block as small as possible but as large as necessary. In short these are blocks of code which alter state of your objects. This means any access to member variables (not method local variables) which could be affected by more than one thread should be correctly synchronized to avoid threading issues.

But as you probably can imagine it's impossible to explain all the details in a few lines and building thread-safe applications is a lot more difficult than building programs without thread-safety in mind. Brian Goetz's book "Java Concurrency in Practice" is a really good source for this topic.

Marco
[ May 15, 2008: Message edited by: Marco Ehrentreich ]
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes..... Rest of the code in the doStuff() will available to all the threads. This is the good adavantage of declaring syncronized block ,over declaring method as syncronized. Because , It keeps the entire code in the method in lock mode.
 
Vierda Mila
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all
 
vijay jamadade
Ranch Hand
Posts: 258
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ya really its too much complex to develop the application using threading when there are more dependancies.

You need to think about so much things that you sometimes even can not imagine

Regards,
Vijay
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not too complex it's just harder Indeed with todays technology there's hardly another way to use the full performance of a machine because you don't get faster CPUs any more. Instead the number of CPU cores are growing which you should effectively use as much as possible by introducing concurrency.
But you should definitely study some books or tutorials to fully understand concurrent programming. And as with most things you need to practice.

Marco
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

Yes..... Rest of the code in the doStuff() will available to all the threads.



I have a doubt,



It is understandable that code that is above the synchronized block is available to other threads.

But how come code that is after synchronized block is available to other threads, as the execution will be sequential.

Please clarify.
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ram, the code lines within the synchronized block are obviously the only statements that are synchronized and can only be accessed by one thread at a time.

Before and after the synchronized block all threads may access this code simultaneously. It may be hard to imagine how this can be a problem if you're new to concurrent programming, though. You have to keep in mind that the statements below and above - even if it's a single Java statement - may result in more than one instruction of the virtual machine. So it's absolutely possible that two or more threads interleave in an undesirable way within only one instruction of Java code! And as I wrote above depending on your requirements and what this statement does this may or may not be a problem. I hope it's more clear now...

Perhaps some additional information to your question. It seems you're thinking all threads will wait until the thread which executes the synchronized block is finished with the entire method but that's not the case. The only thing which is guaranteed with the keyword synchronized is that only one thread can execute this code in this block. Besides every other combination in the order or interruption of execution between multiple threads are possible. And more difficult to imagine: everything is happening in an unpredictable way even for each run of your application.

Marco
[ May 15, 2008: Message edited by: Marco Ehrentreich ]
 
Ram Manoj
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Marco,

The picture of synchronized block became a bit clearer.

My question has become funny.

I was thinking,

Threads have to wait for their turn for the lock on the synchronized object of block is free,
how come if threads which dont' have a lock on the object, go with the execution of rest of the code after the synchronized block in the method.

Now I was able to visualize the right scenario.

Thanks.
 
reply
    Bookmark Topic Watch Topic
  • New Topic