Fork/Join and More Java 5 Concurrency APIs

As I mentioned before, I am going through Programming Concurrency on the JVM by Venkat Subramaniam.

Chapter 3 was about design. He discussed immutability, shared mutability, and isolated mutability.

In Chapter 4 he went over some of the concurrency APIs that were introduced in Java 5.

The Fork/Join framework was not as much of a beast as I thought (although I am not claiming to know the whole thing). It is a lot like dealing with Callables, Futures and ExecutorServices and thread pools. First, you create a ForkJoinPool. Then you make a class that extends  a child class of ForkJoinTask. There are two, and they each have a method called “compute” that actually does the work, sort of like Callable.call(). RecursiveAction.compute() returns void, and RecursiveTask.compute() returns an object.

Your grandchild class of ForkJoinTask might instantiate a few copies of itself in the compute() method. You build up a java.util.Collection of them, and call invoke() or invokeAll() to start the calculations. I guess this is sort of like ExecutorService.submit(). Then you call ForkJoinTask.join to bring the results together. This is all kicked off by ForkJoinPool.invoke() (which returns an object) or ForkJoinPool.invokeAll() (which returns a List of Future objects). ForkJoinPool implements the ExecutorService interface, and ForkJoinTask implements the Future interface. So in a way it is like Callables and Futures, although I am not too clear right now when you would use one versus the other.

He deals briefly with CountDownLatch and CyclicBarrier. He states that there are better ways to do concurrency than Threads and locking, so I did not spend a whole lot of time on these. “CyclicBarrier” sounds like something out of science fiction.

He touched on AtomicLong, and that it is a good way to make a long variable thread-safe. There are also AtomicInteger and AtomicBoolean classes. I wonder why there is no AtomicFloat or AtomicDouble. The API for these says that these should not be used as replacements for the java.lang.Integer and java.lang.Long classes. Yet if you look at the Really Big Tutorial, they kind of do exactly that.

There was also a section on concurrent collections. He pointed out that they have better performance that older collection classes in addition to being thread safe, although he did not spend a whole lot of time on them.

There was a section on the classes in the java.util.concurrent.locks package. It looks like it is a good substitute for the synchronized keyword. although it is pretty verbose. I made a few classes that set and manipulate a few variables, with one using “synchronized” and two others using locks. One used a separate RentrantLock for each variable, and the other used one for the whole class. The main class just goes through a loop, calls some methods and sees how long it took. The class using the “synchronized” keyword was faster. I know that the Lock objects are better at preventing deadlocks, but it does seem like they sacrificed some speed. Perhaps I need to find a better comparison than the one I made.

Dr S. will be here next week for the Austin JUG meeting. Hopefully by then I will be through chapter 6, Software Transactional Memory. It is the longest chapter in the book. I will have to set up some projects for Clojure and Scala. I am doing the Java stuff with Gradle, and I think I am learning as much about Gradle as I am about concurrency.

A Look At Java’s Callable Interface Part 002

As I mentioned before, I am going through Programming Concurrency on the JVM by Venkat Subramaniam. I am looking at the Callable interface. He uses it a few times in chapter 2. I will go over some code I posted last time.

The two files I will go over are CallableWorker and ForwardCallableRunner. There are a few things in the code that are not relevant to concurrency, but still have use. I put in the ForwardCallableRunner.setIterations which will set the number of iterations a loop will run by using a system property, or set a default value if none is provided. I also put in some logging statements and calls to Thread.sleep() to get a better idea of when things are called.

The class that does the concurrent magic is CallableWorker. It implements the java.util.concurrent.Callable interface. It is part of the concurrency APIs that were introduced in JDK 5. It is similar to the java.lang.Runnable interface that has been part of the JDK since the very beginning. The main difference is that Callable can return a value and Runnable cannot. Developers would have to create additional methods to check if their Runnable.run() method had completed. Dr S says that we should use the newer APIs and not bother with the older stuff.

The only method defined by Callable is the call() method. It takes no arguments, and returns an object. If you are returning a Java primitive (like an int or double), you must use one of the wrapper classes in java.lang, like java.lang.Double. You implement the call() method, but you never actually call it. Callable uses generics, so in your class declaration you put:

 

That type should be the same as the type of whatever the call() method returns.

I added a few parameters to the constructor. A lot of examples online that I saw (including the original that I got this from by Lars Vogella) do not use a lot of data. They just increment a variable in a loop. do some simple math, and return the result. If you want to add data to your class to work on, you could either add it via the constructor, or another method, or create the Callable inline, as Dr S does in his examples. I would guess that adding it in the constructor would be better for thread safety. But ulitimately, I just do some simple summing, like most other examples.

The class that creates and uses the Callables is ForwardCallableRunner. I also made a BackwardCallableRunner. They both create some Callables, which sum some numbers in loops. In ForwardCallableRunner, the numbers send to the constructors for CallableWorker increase in the loop, and in BackwardCallableRunner they decrease.

The first thing you need to do when using a Callable is to create a thread pool. The JDK 5 API gives you some classes to do that.

Use java.util.concurrent.Executors to create a thread pool. I use the method Executors.newFixedThreadPool with an integer argument for the size of the thread pool. This will return an instance of java.util.concurrent.ExecutorService.

Executors.newFixedThreadPool is overloaded. You could also call it with an addition argument, which is a class implementing the java.util.concurrent.ThreadFactory interface. There are also a couple of methods that make thread pools of dynamic size: Executors.newCachedThreadPool. You can use the Executors.newFixedThreadPool without specifying a ThreadFactory. There are a couple of other libraries that do implement or return an instance of java.util.concurrent.ThreadFactory: BasicThreadFactory in Apache Commons Lang, and  ThreadFactoryBuilder in the Google Guava library. I have not tried them, so I do not know what they give you beyond what the default implementation gives you.

The next step is to create an instance of  java.util.concurrent.Future, or a list of them. It must be of the same type as the Callable you created before.

The next part of the example is in a loop. In each iteration, I created a Callable, and I sent it as an argument in a call to the method java.util.concurrent.ExecutorService.submit. This will return a java.util.concurrent.Future, which will hold the result of our Callable. The Callable.call method starts when the ExecutorService.submit method is called. (I inferred this from the examples, but I wanted some verification; this is what led me to put in the logging statements.) I then add the Future that was just created to my list of Future objects.

Lastly, I create a for loop to cycle through the Future objects. This shows the next step in our Callable/Future lifecycle. To get the return value of the Callable.call method, you call Future.get. The documentation says that it will wait if the result is not ready yet. This is why I made an example that counts upwards through the number of iterations and one that starts at the iteration number and counts to 0. Since my CallableWorker.call method also does some sleeping, the class with the highest number should take longer. I wanted to see if the for loop with the call to Future.get would actually wait if the next Callable.call was not done yet. Since I got the same result in both classes, I assume that it did.

The last step is to call ExecutorService.shutdown().

Most of the examples are like the one that I worked with: They call ExecutorService.submit for each Callable. Dr S creates a java.util.List of Callable objects, and starts them off by calling ExecutorService.invokeAll. He also creates his Callable objects inline, and does not have a separate Something.java file for them.

So, to summarize, here are the steps to using Callable:

1. Create a class that implements the java.util.Callable interface. (This step could come later.)

2. Create a thread pool by calling java.util.concurrent.Executors.newFixedThreadPool to return an instance of java.util.concurrent.ExecutorService

3. Create a list with type of java.util.concurrent.Future.

4. Call ExecutorService.submit, sending it a Callable object. This will create a Future object, which you add to your list of Future objects.

5. Get the result of all of your Callable.call methods by iterating through your list of Future objects, and calling Future.get on each one.

6. Clean up by calling ExecutorService.shutdown.

Dr S does this slightly differently:

1. Create a list of inline objects that implement the java.util.Callable interface.

2. Create a thread pool by calling java.util.concurrent.Executors.newFixedThreadPool to return an instance of java.util.concurrent.ExecutorService

3. Create a list with type of java.util.concurrent.Future, and instantiate it with a call to ExecutorService.invokeAll. The paramter of ExecutorService.invokeAll is the list of Callable objects created in step 1.

4. Get the result of all of your Callable.call methods by iterating through your list of Future objects, and calling Future.get on each one.

5. Clean up by calling ExecutorService.shutdown.

His way has fewer steps, and fewer lines of code. But honestly I prefer the way most examples do it. I think it is clearer. Doing too much inline looks a bit noisy and crowded to me.

A Look At Java’s Callable Interface Part 001

As I mentioned, I am looking at Programming Concurrency on the JVM by Venkat Subramaniam. I got to an example that used the java.util.concurrent.Callable interface. I then went out looking for some more examples. I have put what I have done up on Github. I used a class by Lars Vogella in my code, and then I looked at a few other examples to see the pattern, and made a couple of my own.

Java had an interface called java.lang.Runnable from the beginning. One issue with it is that it does not return a value. I am not going to look at that too much or all of the methods of java.lang.Thread. The general consensus is that the world should move beyond the old ways.

This post is pretty big with the code, so I will put the code in this post and talk about it tomorrow.

Here is a class that implements the java.util.concurrent.Callable interface.

Here is a class that calls the class we just made.

 

I will go through the code in a couple of days.

2013-05-07 Update

I am pretty late, but here is an update.

I am still working on helping a local developer upgrade his Rails 2 app to Rails 3. I hit a wall. There is a lot of Javascript. I do not know too much Javascript. I asked someone for some help. We will see how things go.

I am kind of thinking about reviving RailsPress. A Rails user group had another thread complaining about WordPress. In addition, there was an article on Naked Capitalism that the site was having some issues with a WordPress host called WPEngine.  WPEngine is in the Capital Factory, an incubator in Austin that hosts the Austin Ruby and Austin Rails groups. If I get RailsPress up and running, I doubt I will be talking about it at the Capital Factory.

I am also looking at Groovy and Grails. I am porting a DNS server written in Java to Groovy. I got the tests written in Spock. I have not started porting the server itself yet. Getting the tests from JUnit to Spock took a while.

I am also looking at Java concurrency. I am going through Programming Concurrency on the JVM by Venkat Subramaniam. I don’t know if I will ever use some of this stuff (I might use GPars in my Groovy DNS port), but this has been a big hole in my Java knowledge that I think it’s time I should fill. I might post about the Callable interface.

2013-04-06 Update

Not too much happened this week.

I met with the dev whose app I am upgrading from Rails 2 to Rails 3. His app helps people transcribe documents/books/papers. He deals with people who have interesting collections. He is involved in a few projects that could be huge in the digital archiving space. I am pretty much done with all the Ruby stuff. Now I have to add some JQuery.

There was an Austin Groovy meeting. I think that there will be some interesting things happening in the Groovy space going forward.

I am involved with the SciRuby project. I might curtail that a bit and use Commons Math and Groovy to learn linear algebra for now. It would be good practice with Groovy, and I am more familiar with the JDK. I would like to encourage scientific computing in Ruby, but for now NMatrix requires some hand-compiled C libraries. Right now it does not work on Ruby 2. And someone wants to contribute a library that runs on JRuby. I like Java, I like Ruby, but I don’t like putting them together.

I have heard there are a lot of Java shops that are running JRuby to transition from Java to Ruby. If a Java shop wants to try out dynamic languages, I think they should look at Groovy.

Maven Repositories

A lot of Java projects manage their source code via Maven. There is the searchable Central Repository. JBoss has a page of their repositories.

But there are other Maven repositories. Here is a list of a few others that I have used and found via the web, in no particular order.

Post updated 2013-08-22_23.07.54

2013-01-20 Update

So I am looking at a Java job. From what I have been told, there is a lot of REST involved, so I am trying to get through a Jersey tutorial. I was having a lot of issues with Eclipse. I could not get it working with Tomcat. It turns out I had the wrong bundle. There are a lot on the “Download” page. “Eclipse for Right-handed People”, “Eclipse For Redheads”, “Eclipse for Australians”, etc, etc. I just want Eclipse, dammit.

I got it to run with Tomcat, but every time I tried to run the Jersey example, the Eclipse UI would crash. Tomcat would still be running, so I could still call the service. And Eclipse would be running in the background. But I had to keep killing it (at least I think I did) and restarting it. That got old fast, so I am going to try it with Netbeans. I always felt more comfortable with Netbeans. There are not as many plugins, so you have to do more things yourself, but having fewer versions makes it easier in some ways.

2012-09-04 Thoughts on Clojure

I am looking at Clojure more these days. Right now I am going through the Clojure lectures on Pluralsight. I came for the concurrency. I stayed for the elegance.

From what I have heard, it handles concurrency better than most other languages. At Lone Star Ruby Conf, a few presenters talked about how Ruby will handle the coming “concurrency freight train”. Robert Martin said that we should look at a purely functional language. I think that was a hint to look at Clojure and avoid Scala.

I am looking at a great site called Clojure Docs, which I heard about from Colin Jones. It has better documentation than the official Clojure site. The docs at cloure.org for ->> are not useful at all. And good luck googling that.

A few weeks ago I attended a presentation at Geekfest about logic programming in Clojure. One of the examples the presenter gave was about chess. He programmed the rules of chess in his application. From there, you could arrange some pieces, and the applicaiton could tell you if that particular arrangement could have resulted from a legitimate game of chess, and what the moves would have been, and also what could happen going forward.

Someone asked me why you couldn’t do that with a rule engine, and honestly I did not have an answer.

But still, I can see how logic programming could be useful for scientific research. You could say that some material could handle X pounds of pressure per square inch. Good stuff.

Some Info on Dates in Java

On Friday I was helping a Rubyist with some Clojure. She needed to format a date, and wanted to use some Java to do it. I sent her some info in an email, and thought that I would share it here.

If you are just going to get the current time and futz with its format, then using java.util.Date and java.text.SimpleDateFormat should be sufficient. There are a lot of deprecated methods in java.util.Date. Pretty much all of them are setters and the constructors for making a Date other than the instant it is created. If you need to change the fields, then you should use java.util.GregorianCalendar. If you need to use GregorianCalendar, then you could call the GregorianCalendar.getTime() method, which returns a java.util.Date object.

With java.text.SimpleDateFormat, you can either supply the format in the constructor, or with the “applyPattern” method. You use the usual y, M, d, etc for the formatting. Here is the formatting page: http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html

So here is some code:

Here is the output:

I honestly wasted about 5 minutes at first because I was trying to force Ruby into the Java code (by trying Date theDate = Date.new()) and not realizing why the compiler was not cooperating. Kind of like when I tried (x * n) in Clojure on Friday before I remembered it should be (* x n)

 

Notes From No Fluff Just Stuff November 2011

I attended the No Fluff Just Stuff conference here in Chicago back in November 2011. I took  a few notes on some of the lectures. Here are my notes on some of the lectures on concurrency. I may post in a while with notes from more lectures, as well as some more thoughts on concurrency.

Venkat: concuurrency without pain in pure Java
Why Concurrency?
Java gave us a consistent API for multi-threading
Errors are worse on multi-core machines – multiple levels of cache in application
To get concurrency correct, you have to be God.
That model is the synchronize and suffer model
2 other models: Software Transaction Memory and Actors

Synchronized helps you cross the memory barrier synchronizing main and working memory
Locking and race condition is only part of the story
Do not synchronize the accounts, synchronize the transactions
You should also synchronize in the class using the Account classes

There could be livelock or deadlock
But you could wait a long time.
But you cannot tell synchronized() to timeout.

So instead in Account, use a ReentrantLock
in Account.deposit method, use ReentrantLock.tryLock(long, TimeUnit)

This makes code more complex. synchronized blocks are pretty easy.
Don’t forget to call Reentrant.unlock()
But what if there is an exception before that? Put it in a finally.
This is why we don’t use raw JDBC

Deadlock: I have lock on A, I need a lock on B. You have a lock on B, you need a lock on A.
You could impose an order
If someone introduces a new method, all your locking could be ruined. It’s like a bathroom with a lot of doors. You got to lock every one.
Concurrency on JDK is like a mother-in-law: It’s waiting for you to fail.
95% of Java is broken for concurrency, and we don’t know it yet.

STM: Software Transaction Memory
Everything is immutable (almost everything)
Managed Mutable Identity is also in Clojure
Sharing is good, mutability is good, shared mutability is bad
Separates state from identity
identity points to state
Like stock price: $600 at 1:00 PM, $610 at 1:10
The price at 1PM on November 11, 2011 will always be $600
We can flip a switch to point identity to a new value
Immutability means no locks

the problem is not that it is failing, but that it is misbehaving quietly and you do not know it.
MMI fails loudly if you mess with it outside of a transaction
transaction thread runs in a cone of silence
final change is visible to outside world

If there is a collision, a transaction could repeat
Clojure is written in Java – it’s another JAR, and you can use it in Java

change int in Account to clojure.lang.Ref

int will be replaced with java.lang.Integer
You can only put immutable stuff in there.
Also

Clojure:

You could still have race conditions. The AccountService that does the transfer still needs a transaction to wrap around the transactions in the Account classes
A transaction in STM could repeat 100,000 times – so do not print, send email

STM: we don’t see any locks (so no deadlocks)
2 drawbacks:
1. STM requires state be immutable – greate for Clojure – the only language where concurrency is safe
2. Code could ge slow or fail due to retries
Hard to be functional in Java
Another option: Isolated mutability – only one thread can touch it at a time
Actors and active objects
An actor can receive many messages at once, but they only work on one at a time
Akka library – now we use Scala’s implementation
Akka gives us STM and Actors

So we passed a message. We did not call a method directly.
Actors do not hold Threads hostage
Actors could fail
Each Actor is sequential
Could deadlock with 2-way messaging

JDK concurrency APIs are assembly language of concurrency

But can Java web developers do this?

Ted Neward Guava:
Get rid of mutable state