• Post Reply Bookmark Topic Watch Topic
  • New Topic

Synchronization costs  RSS feed

 
Tim Williams
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am aware that synchronizing on an object costs a certain amount in terms of performance.
If however I have an object and I know my code is the only place with that object reference what kind of performance hit do I incurr if I synchronize on it. Is it so small as to be almost insignificant?
I know this sounds pointless - but I do have a good reason (just too long to explain right now).
Thanks for the help,
Tim.
[ July 10, 2002: Message edited by: Tim Williams ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm moving this to the Threads and Synchronization forum...
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Usually when people talk of the performance penalties of synchronization, the biggest effect is what happens if another thread already has the lock you need, and you have to wait for it. Compared to that, the time required to acquire an uncontested lock is relatively small. But whether it's "insignificant" will really depend on what else you're doing in your code. If it's in a tight loop, repeated many times and there are few other activities in the loop which are time-intensive, it can be sigificant. But in many other cases, it won't be. For a better answer you really should measure performance with and without synchronization in your application.
 
Tim Williams
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not using any looping, there is just the one lock to acquire and hold while messaging a 'legacy' system. Once I get my response I can release the lock.
I think I need to perform some measurements but the general principle looks sound.
Thanks for the prompt reply.
Tim.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim is absolutely correct. The big cost of synchronization comes in when various theads end up competing for the object's lock. The other part of it isn't really that costly.
But in case you're interested, here's what's involved.
When your thread needs a resource(say a Vector), and it _doesn't_ synchronize on that Vector, it makes a local copy in Thread Memory, uses that copy, then writes the result back out to main memory. This is where problems can come in, because other threads could be doing the same thing, thus overwriting each other's changes unexpectedly.
However, when your thread synchronizes on that Vector, then it doesn't make the local copy: it actually communicates with Main Memory each time it needs the Vector( in addition to setting a lock on it, so other synchronized thread don't get in the way).
This is an overgeneralization, of course, and a little off on the details, but it's close enough for horseshoes.
I suggest reading up on the java spec regarding Threading: it's an amazingly easy read.
HTH,
M
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Max's description sounds more like what happens when a field is declared as volatile. For synchronization, a local copy is made once when you first enter the synchronized block or method. Later when you leave that same method or block, the local data is used to update the main memory. The idea is that there's no need to keep checking main memory for every data access, since no other threads should be able to interrupt while you're in the synchronized block. (Unless of course they have other access methods which are unsynchronized - but that would be your fault for not synchronizing all access.)
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy Jim,
There's no constraint forcing a synchronized block to write out the value contained in Thread Memory to Main Memory only when the lock is release: it could do it after any assign. The OS is free to write out the changes intermittently, or in one big push at the end. That's why we have to be so careful. The only guarantee is that before unlocking, the Thread flushes out the content to Main Memory. Thus, an unsynchronized reader method that reads the value of the variable in question during the original Thread's execution could be reading a halfway changed value.
M
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, when people are concerned about the time of synchronization they are not so much concerned about blocking.
They are concerned about the time it takes to get and release the lock. That is where the time is eaten away. For instance

in this case, the time to execute this loop will be different if doIt were synchronized vs. if it were not.
Of course you mileage may vary. You will basically have to profile your target machine to find out the impact.
Since you are just locking once and doing your thing, the lock time will be completely insignificant.
As for volatile, it is unrelated to synchronization and is used for completely different reasons. However, I should note that volatile variables do get copied into thread local memory too.
[ July 11, 2002: Message edited by: CL Gilbert ]
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
CL,
Yes and no. Yes, people generally _are_ concerned with the time it takes to get/release the lock. However, they _should_ be concerned about the contention involved. IMO, that's the real issue.
 
Tim Williams
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've learned more than I bargained for already, thankyou. So while I'm feeling keen what are people's favourite/recommended books on threads and this kind of stuff?
Tim.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Easy.
Taming Java Threads, Allan Holub(Apress).
Threads, by someone and Wong(O'Reily).
Concurrent programming, Lea(forgot publisher).
Of course, I hear that The Sun Certified Java Developer Exam with J2SE 1.4
also has an excellent section on Threading :-)
HTH,
M
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Max Habibi:
CL,
Yes and no. Yes, people generally _are_ concerned with the time it takes to get/release the lock. However, they _should_ be concerned about the contention involved. IMO, that's the real issue.

Contention is a result of safe behavior. I don't see anyway around it. If you have unnecessary contention, then yes, you need to rid yourself of it. I guess I see your point. Depends on your type of program and your objective of multithreading.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by CL Gilbert:

Contention is a result of safe behavior. I don't see anyway around it. If you have unnecessary contention, then yes, you need to rid yourself of it. I guess I see your point. Depends on your type of program and your objective of multithreading.

I completely agree with you about the neccessary evils of contention. But my point here is that contention is _much_ more expensive then simply locking/unlocking a resource for which there is no contention.
If you compare the order of magnitude between the difference in a synchronized block and an unsynchronized one, vs. the order of magnatiude difference between a an a synchronized block and a synchronized block _with_ contention, I believe you'll weep. I know I have

[ July 12, 2002: Message edited by: Max Habibi ]
 
Leslie Chaim
Ranch Hand
Posts: 336
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Max Habibi:
Easy.
Threads, by someone and Wong(O'Reily).

That someone is Scott Oaks, and its the best of the three listed. I just completed all three, I would recommend starting with the 'Java Threads' by O'Reilly then tame them with Allen's help.
Doug Lea's book is more abstarct then the others It really depends whether you like abstracts follwed by specifics or specifics followed by abstracts.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Leslie,
Duh, don't know how I forgot Scott's name: just wasn't there when I reached for it. It is an excellent book, though Holub's book is my favorite, just because he does stay very specific.
M
[ July 15, 2002: Message edited by: Max Habibi ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The big cost of synchronization comes in when various theads end up competing for the object's lock. The other part of it isn't really that costly.

I've recently read in a Java book (sorry, forgot the title, but can look it up) that the other part of it is very costly. The example included a code where there was only one thread created (and thus no competing for a lock), and the synchronized method was executed in a loop. The result was that if the method was not synchronized, the same code executes 10 times faster, or so.
Eugene.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, it's all relative. Competing for a contested lock is definitely more costly than competing for an uncontested lock, and many books and articles seem to advocate "avoid synchronization to enhance performance" without bothering to distinguish between the two cases. Acquiring an uncontested lock takes nonzero time, true, but whether it's "significant" depends on what you're comparing it to. I'm betting that whatever loop was used to demonstrate the time penalty in acquiring a lock, it probably did very little (in terms of complexity) other than acquiring a lock. But I'd be interested in learning more about either the book, or the method used to demonstate the performance cost, if you have the time. Thanks...
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seems like an easy enough thing to test. We'll write a snippet that calls a method, say, 3000 times. Then synch the method, then create competing threads. Fair enough?
M
 
Jim Baiter
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, it's all relative. Competing for a contested lock is definitely more costly than competing for an uncontested lock, and many books and articles seem to advocate "avoid synchronization to enhance performance"

I would say the idea would be to perform a proper analysis in order to minimize the size of critical sections. There is no need to synchronize say a whole 10 line method when only one line is not thread safe.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim,
Limiting the size of the synchronized block can certainly help, but it's not a end all solution, percisely because locking/unlocking is not free. As a somewhat contrived example, consider the following:

versus

The latter can be much more expensive, depending on contention: there's cost associatied with checking resources, swapping threads in and out, co ordinating competing threads, etc. All in all, the best way to go forward is to know your stuff, and do specific system testing.
HTH,
M
 
Jim Baiter
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think you understand what I was saying. I am referring to synchronizing code that does not need to be synchronized. Peter Haggar's book has some good illustrations.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim,
This goes directly to the way that Threading memory interacts with working memory withing the JVM. When a Thread performs a lock action on a given variable, it flushes all of the globally available variables. the lock action is then (usually) followed by either a use or and assign action, and then an unlock, which flushes the variables back out to main memory again. This is the important point it. the thread doesn't just do this for the locked object, it does so for all used variables potentially shared with other threads.
In english, it's pretty much just as expensive to lock the entire method as it is to lock a single line. Generally speaking, it's more expensive(in terms of processing time) to lock and unlock a variable twice in the same section of code, because you only needed it for, say, two lines out of ten. Of course, there are always counter examples, but this is the rule of thumb. take it for what it's worth to you. For more information, try here.
Best regards,
M
The Sun Certified Java Developer Exam with J2SE 1.4
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!