Concurrency

One thing I did not quite get when I was looking at multithreading technologies was how to unit test them.

I have not looked at Akka for a while, but a few years ago it seemed like the consensus was to use a logger like Log4J, and then parse the logging messages. That is kind of unwieldy and feels wrong. (Akka seems to have more ways to test now.)

I emailed the GPars list about putting private fields in an actor, changing them in the onMessage method, and then checking them afterwards; something like this:

class BadActor extends DynamicDispatchActor {
    private def someField
    private def someOtherField
    
    void onMessage( ObjectType message ) {
        someField = message.doStuff()
        someOtherField = message.doOtherStuff()
    }
}

You could do that. There is nothing wrong with having private fields in an actor. You might want to keep some data between requests (like an encryption key). But making a field just for testing seems wrong.

Then I had an idea: Have your actor call another class that does the actual work, and unit test the worker class:

class BetterActor extends DynamicDispatchActor {
    
    void onMessage( BetterObjectType message ) {
        def worker = new WorkerClass( message )
        def result = worker.doWork()
    }
}

I suppose that will not help with functional testing. It might violate some SOLID principle, or DRY, or GRASP or the Law of Demeter or Principle of Least Astonishment or Poe’s Law, but it seems like a pretty good idea to me.

You’re welcome.

Image from the “Imperial Menologion“, an 11th-century Byzantine manuscript, not to be confused with the Menologion of Basil II. Manuscript  housed at The Walters Art Museum, manuscript information here, image from World Document Library, image assumed allowed under Fair Use.

I have played around a bit more with closures and locks in Groovy.

In one of Venkat S’s talks, he says that the java.util.concurrent.locks package solves a lot of the issues with the synchronized keyword: You have to have try/catch/finally blocks to get the lock and release it. I made a class that will hold a Lock object, and can take code as a closure and run it. It seems to work pretty well. At least I think so.

But I realized there is one possible issue: The ClosureLock class only imports from java.util.concurrent.locks. What if some of the code in the closure is from another package that is not imported in the ClosureLock class?

I made a class that imports groovy.time.Duration, and creates a couple of objects and invokes methods in a closure. And it ran without blowing up. I also made a class called DebugClosureLock that prints out some stuff to the console checking if the lock is held by the current thread.

Here is the DebugClosureLock class:

package info.shelfunit.concurrency.locks

import java.util.concurrent.locks.Lock
import java.util.concurrent.locks.ReentrantLock

class DebugClosureLock { 
    final Lock lock = new ReentrantLock()
    
    // prevent lock from being changed
    def setLock( arg ) {}
    
    def lockSomeCode( block ) {
        
        try { 
            println "Is lock ${lock.hashCode()} held? ${lock.isHeldByCurrentThread()}"
            println( "about to try to get the lock" )
            if ( lock.tryLock() || lock.tryLock( 500, TimeUnit.MILLISECONDS ) ) {
                println " About to call block. Is lock ${lock.hashCode()} held? ${lock.isHeldByCurrentThread()}"
                block.call()
            }
        } finally {
            println( "About to try to unlock" )
            lock.unlock()
        }
        println "Done with code. Is lock ${lock.hashCode()} held? ${lock.isHeldByCurrentThread()}"
    }
}

Here is the class that uses it:

package info.shelfunit.concurrency.locks

import groovy.time.Duration 

class SecondLockRunner { 

  def doStuff() { 
    DebugClosureLock cLock = new DebugClosureLock()
    def dur = new Duration(  30, // days 
        2, // hours 
        45, // minutes 
        32, // seconds 
        123 // millis 
    )
    println( "about to call dur.toString() " )
    cLock.lockSomeCode( { println "${dur.toString()}" } )
    def dur2 = new Duration(  3, // days 
        20, // hours 
        43, // minutes 
        31, // seconds 
        522 // millis 
    )
    println( "\nabout to call dur2.toString() " )
    cLock.lockSomeCode { 
        println "${dur2.toString()}"
        println "dur2 as long: ${dur2.toMilliseconds()}"
    }
    
  }

  static void main( String[] args ) { 
    SecondLockRunner slr = new SecondLockRunner()
    slr.doStuff()
  }
} // end class

So, to review: My question was would DebugClosureLock blow up when it was called since it does not import groovy.time.Duration? And the answer is it did not.

Here is the console output:

about to call dur.toString() 
Is lock 1740808647 held? false
about to try to get the lock
 About to call block. Is lock 1740808647 held? true
30 days, 2 hours, 45 minutes, 32.123 seconds
About to try to unlock
Done with code. Is lock 1740808647 held? false

about to call dur2.toString() 
Is lock 1740808647 held? false
about to try to get the lock
 About to call block. Is lock 1740808647 held? true
3 days, 20 hours, 43 minutes, 31.522 seconds
dur2 as long: 333811522
About to try to unlock
Done with code. Is lock 1740808647 held? false

Paul King shows how to do this on slide 36 of his talk Groovy and Concurrency using metaprogramming:

import java.util.concurrent.locks.ReentrantLock

ReentrantLock.metaClass.withLock = { critical ->
    lock()
    try { critical() }
    finally { unlock() }
}

Then you can use it like this:

ReentranLock lock = new ReentrantLock()
lock.withLock{ someCode() }

You’re welcome.

Image from “Evangeliarium [Evangéliaire dit de Charlemagne ou de Godescalc]”, an 8th century manuscript housed at the Bibliothèque nationale de France. Source gallica.bnf.fr / BnF; image assumed allowed under Fair Use. It also has a Wikipedia page.

There is an example of using threads with Groovy in Venkat’s book.

He uses the GDK extension to Thread and calls Thread.start. I wondered if the main thread would wait until the started thread completed, and what would happen if you started another thread.

I made some changes, and ran it.

Here is my class:

package info.shelfunit.venkat.ch07

class BetterThreadExample {
    
    def printThreadInfo( msg ) {
        println "$msg" 
    }
    
    def doStuff() {
        sleep( 5000 )
        printThreadInfo 'Main'
        println "Main is ${Thread.currentThread().name}"
        Thread.start {
            def name = Thread.currentThread().name
            printThreadInfo "AA Started: ${name}"
            sleep( 3000 ) 
            println "AA Interrupted 1" 
            sleep( 1000 )
            println "AA IN started"
            sleep( 3000 )
            println "AA still in started"
            println "AA Finished Started"
        }
        
        Thread.start( 'Second' ) {
            def name = Thread.currentThread().name
            printThreadInfo "BB Started Daemon: ${name}"
            sleep( 5000 ) 
            println "BB Interrupted 2" 
            sleep( 1000 )
            println "BB in second thread"
            sleep( 1000 )
            println "BB Finished Started Daemon"
        }
        println "At the end in main"
    }
      static void main( String[] args ) { 
          def bte = new BetterThreadExample()
          bte.doStuff()
      } // end method main

}

Here is the result:

Main
Main is main
At the end in main
AA Started: Thread-1
BB Started Daemon: Second
AA Interrupted 1
AA IN started
BB Interrupted 2
BB in second thread
BB Finished Started Daemon
AA still in started
AA Finished Started

So the main thread gets to its last statement pretty quickly. The two threads run simultaneously. I already knew this, but it’s good to review threads every now and then.

I was always intimidated by threading and concurrent  programming. Maybe it’s not too bad in Groovy.

You’re welcome.

Image from Aurora Consurgens, a 15th century manuscript housed at Central Library of Zurich. Image from e-Codices. This image is assumed to be allowed under Fair Use.

In a previous post, I wrote about using lambdas in Java to simplify the use of locks. I was able to get this up and running in Groovy.

I have the code for it at Github. I made a class called ClosureLock which has a method called “lockSomeCode” which takes a closure as the argument. It creates an instance of ReentrantLock, and calls the closure in a try/finally block. Now that I look at it, i suppose I should refactor it so the ReentrantLock is a private variable and can be re-used, since ClosureLock can be reused.

I also created a class called FirstLockRunner, which instantiates ClosureLock and uses it a few times.

After I figured this out, I did some googling, and a few other people have done this before. A guy named David Clark has a class called DemoLockEnhancements in a project called GroovyThreading.

A guy named Johannes Link also did something similar.

There are a couple of new Groovy books out. I think I will look them over in order to understand closures/lambdas better. I have been reading that lambdas can be used to improve concurrency in Java and are thread safe.

I know that the consensus is to move away from locks and instead use other concurrency techniques. But I think that if locks can be done cleanly and safely, then their use should be considered.

Image from Rudolf von Ems’ Chronicle of the World, a 14th century manuscript housed at Central Library of Zurich (Wikipedia page here). image from e-Codices, assumed to be allowed under Fair Use.