Win a copy of Java Challengers this week in the Java in General forum!
  • 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
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

Why is Java synchronized keyword so slow?

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Recently I had a discussion with a friend about concurrency in java and he asked me as to why is the synchronized keyword either around a block of code or method slow. I answered back saying that it is slow because it contends for an object monitor. Also it gives a happens before guarantee and it has to synchronize all the variables in it's cache with main memory and at the end of the block it has to flush the cache back. It also prevents compiler as well as cpu reordering of instructions. However he said that these do lead to a slowdown but this is not the main reason for performance degradation. Essentially even if there is no contention when a thread hits a synchronized block it switches from user mode to kernel mode and the thread has to save state and then when it leaves the block it has to once again reload the state. I am trying to find literature on the web that describes this but I am unable to find any. I am wondering if anyone can confirm this is correct? Why should java threads enter kernel mode when it hits synchronized and why not before that? I am asking about the explicit switch from user mode to kernel mode and it this causes a performance degradation?
 
Marshal
Posts: 26529
81
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There's a hidden assumption in that question, which I think you can see easily. So why didn't you question the assumption instead? After all perhaps the assumption is false and you're trying to make up an explanation for a non-existent phenomenon.
 
Ranch Hand
Posts: 165
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Salil Surendran wrote:Essentially even if there is no contention when a thread hits a synchronized block it switches from user mode to kernel mode and the thread has to save state and then when it leaves the block it has to once again reload the state. I am trying to find literature on the web that describes this but I am unable to find any. I am wondering if anyone can confirm this is correct? Why should java threads enter kernel mode when it hits synchronized and why not before that? I am asking about the explicit switch from user mode to kernel mode and it this causes a performance degradation?


I can't provide any references but it is clear that there would need to be a change mode to kernel in order to service the memory barrier instructions that would necessarily be invoked both for entering and exiting a synchronized block or method. This is simply because a memory barrier would be a privileged instruction not accessible from user mode.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic