Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Can we implement Thread Level Speculation in java?

 
KuldeepSapient Singh
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need some assistance regarding the TLS ( Thread Level Speculation) in Java. I need to do a proof of concept for any sample sorting program in java to do the performance evaluation (like memory usage, time consumption etc) for single threaded, multi threaded and sepculative multithreaded program java program. Can someone provide me the algo. to implement the speculative mutithreading in java

Any pointers will be appreciated.
 
Henry Wong
author
Marshal
Pie
Posts: 21405
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
KuldeepSapient Singh wrote:I need some assistance regarding the TLS ( Thread Level Speculation) in Java. I need to do a proof of concept for any sample sorting program in java to do the performance evaluation (like memory usage, time consumption etc) for single threaded, multi threaded and sepculative multithreaded program java program. Can someone provide me the algo. to implement the speculative mutithreading in java

Any pointers will be appreciated.


Thread speculation, meaning executing code that may or may not be needed, is a pretty large (and complex) subject. There isn't really a standard "algo" to implement it in Java.


In my opinion, the easiest example of this, is if you use the Azul JVM. With the Azul JVM, it is possible of a synchronization lock to be speculative. When a lock grab occurs, the JVM (with hardware support) will allow multiple threads to own the same lock. With the lock owned speculatively, memory reads/writes are tracked, and not flushed to memory, until the lock is released. Once the lock is released, the L1/L2/L3 caches are then flushed to memory atomically.

If more than one thread owns the lock speculatively, then both threads behave in the exact same way -- provided that they don't get a cache collision. If a collision occurs, then the speculation failed (the two threads used the same memory), and one of the threads get wind back to the lock grab (the caches updates for that thread from that lock grab are also deleted).

And of course, I call this the "easiest" example because it is not hard to find. Practically, every synchronization block, that is relatively short lived, and doesn't do I/O can be speculative with the Azul JVM. The synchronized collection classes can all be considered in this category.



Another example is related to optimistic locking. In my opinion, many algorithms that use optimistic locking are speculative algorithms. In that case, no actual lock is used. Instead, the initial values are taken, processing is done with temporary variables, and then the final result is stored using a CAS operation. A CAS is an atomic operation that set a value on the condition that the previous value is a particular value. In this case, you want to set the result only if the initial value hasn't changed. If the value has changed, then the speculative processing has been wasted -- and the result is tossed.

For example use of optimistic locking, see the classes in the java.util.concurrent.atomic package.... Also, here is an example that I wrote many years ago...

http://www.coderanch.com/t/566490/threads/java/AtomicDouble-class-update

In this example, here is code that multiply the current value with another value...
Notice that no locks are used -- instead, it will speculatively multiply the value and store the result. If the original value changed, then it will toss the result (speculation failed), and try again.

Henry
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic