• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread-Specific Confinement  RSS feed

 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
quote from Doug Lea: Concurrent Programming in Java Second Edition, page 106:
No synchronization is necessary for either reads or writes to thread-specific fields from within the thread. However, the access paths via currentThread or internal ThreadLocal tables are not likely to be any cheaper than uncontended synchronized method calls. So the use of thread-specific techniques generally improves performance only when objects would otherwise need to be shared and heavily contended from across threads.
I don't quite understand this passage, anyone please explain a little bit to me? Thanks a lot in advance. Before this passage, thread-specific confinement including currentThread and ThreadLocal was introduced in the book.
Regards,
Ellen
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see why a paragraph like that could cause confusion. Here's what I think Doug is saying, although I don't have the book to check context.
Suppose you have hundreds of little jobs being passed to a thread pool with just a few threads. Each job needs to generate a unique ID, among other things, and maybe write some data to disk or a database. You worry about the cost of synchronization, so you come up with this clever scheme: Rather than having a single unique ID generator synchronized across all the threads, each thread in the pool is created with its own generator. If there are N threads, then the first thread's generator just spits out the numbers 1, N+1, 2N+1, and so on. Thread two gets numbers 2, N+2, 2N+2, .... Each job in the pool fetches the generator from a threadlocal and uses it without any risk of contention.
Lea's saying that all the trouble to eliminate contention here wasn't necessary -- it may not have saved you anything at all. Particularly given that these threads will spend a lot of time accessing disk, most of the time only one thread will be getting an ID. The cost of a single thread getting and releasing an open lock is not likely to be higher than the cost of accessing a ThreadLocal, not to mention the memory cost of maintaning more ID generator objects.
[ February 20, 2004: Message edited by: David Weitzman ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[This was composed without seeing David's reply, so "he" means Doug Lea. - Jim]
He's talking only about performance here, comparing thread-specific techniques to techniques involving synchronization. There's a common belief that "synchronization is slow", but it's worth remembering that (a) there can be a big difference between contested synchronization and uncontested synchronization, and (b) techniques to avoid synchronization may be slow too (at least compared to uncontested synchronization). If many threads are trying to acquire the same lock at the same time, or if just a few threads are trying, but whichever one wins will hold on to the lock for a long time - that's contested synchronization. That means threads are frequently unable to proceed because they don't have the lock they need. That makes as application slow. But that doesn't mean that all synchronization is slow. If most of the time locks are available when they're needed, then the process of acquiring a lock can be relatively quick, no slower than calling a simple method. So, if there's not much lock contention,

is probably comparable in speed to

or

because the latter techniques have some extra method calls to currentThread() or get(), plus casting - the time required for these actions is comparable to the time to acquire and release a lock. If another thread isn't using the lock.
Did that help?
[ February 20, 2004: Message edited by: Jim Yingst ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!