Category Archives: Concurrency

Venkat S Was In Austin

I still am going through Programming Concurrency on the JVM by Venkat Subramaniam.

I have hit a bit of a snag. I am on the chapter covering Actors. He uses the Akka library, but he uses an old version of it. A lot of the packages have changed, and I could not find some of the classes in the documentation. I would like to say that it is nice that they now have javadoc in addition to scaladoc. Frankly, I am not too thrilled with Scala. The Java code that calls Clojure STM classes still works.

Also: Venkat S was here a couple of days ago to speak at the Austin JUG. He gave the same concurrency talk I saw a couple of years ago at No Fluff Just Stuff. I took some notes, and I will post them in a few days. Some of the Java 8 stuff looks interesting.

 

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.

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.

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.

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

What Happens After Code Academy?

What happens after Code Academy?

At this point, I have no idea.

The goal is to get a job, perhaps an apprenticeship that leads to a job.

Right now I am trying to nail down my living situation. I have to find some storage for my stuff. Granted, if I am putting stuff in storage that means I probably need to get rid of some stuff.

I may go to Rails Conf.  First I have to get depressed about the hole it will put in my savings.

I am also trying to get an RSpec study group started here in Chicago. I could start building apps right and left, but I would like to do it the right way, with TDD and BDD.

As far as jobs, I would like to get a Ruby/Rails job. I just spent a lot of time learning it. I am not too thrilled with Java these days. There are too many web frameworks that are awkward to test and develop with. There are a lot of companies using old versions of these frameworks as well. There are too many ways to do concurrency. I think over time the Akka library will push a lot of stuff aside.

Sidebar: Why didn’t Sun just use Actors for concurrency in Java from the beginning? Or add them later instead of adding another concurrency API for every other version of the JDK? It is interesting that this is so convoluted in Java and there are so many ways to do it, yet when you talk to the Erlang people, they say, “We just use Actors.” And they have been happy with that for more than twenty years.

I was talking several months ago to someone at Groupon about threading and concurrency in Rails and Ruby. He said that those are things that they do not really worry too much about. He said, “Come to the dark side. We have cake.” That started my journey to Ruby and Rails.

Last Lombok Refactoring

This is the last refactoring example of deadlocked Java code using the “synchronized” keyword.

This example is from a site called Rose India.

I was not able to really use Lombok for this example. The classes that deadlocked extended Thread, and the only method in those classes was the run() method. I did not know if annotating run() with the Lombok annotation would work. The method run() was not marked with the “synchronized” method in the original. Instead there were two synchronized blocks in the run() method. The two classes were using the same String objects to lock, which is why there was a deadlock.

So I decided to do by hand what Lombok does behind the screens. I created a private final object in each method and used those for one of the locks. Just as in the other examples, the deadlock was broken.

Here is the original;

Here is the output of the original:

Here is the refactored version:

Here is the output of the refactored version:

 

Image from Wikipedia page for the Indonesian province of Central Java

Third Lombok Synchronized Example

East JavaHere is another installment of my exploration into concurrency in Java. I have written about finding the Lombok library which uses annotations to reduce boilerplate in Java code.

One of the annotations provided by Lombok is @Synchronized. It is to replace the “synchronized” keyword and prevent some of the problems that can come with using the “synchronized” keyword. There are other annotations available via Lombok, but I have not looked at them.

Here is the third example of a program with a deadlock using the “synchronized” keyword that I refactored with Lombok. I got this example from the Java 2S site.

For this one I have also included the output of each of the programs.

Here is the program:

Here is its output:

There is a line that says “Ending method main”, but it does not end unless you kill the program.

Here is the program refactored with Lombok:

Here is the output of the refactored program:

The image is the coat of arms of the Indonesian province of East Java