Nested Synchronize Blocks

In my new simulation project I have different threads accessing objects. The simulation server calculates periodically their states and the tournament server, handling all agents, is accessing them over distributed Ruby. Therefore I need to synchronize the sim objects. My first attempt looked something like this:

class SyncObject

  def initialize
    @semaphore = Mutex.new
  end

  def synchronize &block
    @semaphore.synchronize &block
  end

end

Before changing something in the sim objects, I synchronize them :

  object.synchronize do
    # change the state of the object
  end

But as things were growing, I suddently got some deadlocks. After some research I found out, that a thread was invoking synchronize on the same object multiple times. The semaphore object doesn't care which thread is locking it. As long it's locked it will block all threads until the block is finished. Even if it's the same thread, that locked the semaphore just before.
But I needed a different behaviour, I want to synchronize the objects from different threads. As far as I remember Java's synchronize behaves the same way.
Using rspec we could specify this behaviour with 2 tests:

it "should not block the same thread when synchronizing" do
    object = SyncObject.new
    object.synchronize do
      object.synchronize do
        object.synchronize do
          true.should be_true
        end
      end
    end
  end

it "should block two different threads when synchronizing" do
    object = SyncObject.new
    wait_for_me = true
    object.synchronize do
      Thread.fork do
        object.synchronize do
          wait_for_me = false
        end
      end
      sleep 1
      wait_for_me.should be_true
    end
    wait_for_me.should be_false
  end

The first test's pretty straight forward, we want to allow nested synchronize blocks for the same thread.
For the second test we need two different threads. The first thread locks the object and lunches a second thread. The first one returns immediately after fork, while the second one is launched in the meantime. So while the first is waiting for a second, the second thread is trying to achieve the lock and is blocked until the first one releases it on line 12. Only now the second thread gets access to the object and can set wait_for_me to false.
Of course both tests fail (or get some deadlocks) with the implemention above. The second version of synchronize looks now like this:

class SyncObject

  def initialize
    @semaphore = Mutex.new
  end

  def synchronize
    unless @current_thread == Thread.current
      @semaphore.synchronize do
        @current_thread = Thread.current
        yield
        @current_thread = nil
      end
    else
      yield
    end
  end

end

The first time synchronize is accessed, @current_thread is set to the current running thread. The semaphore is locked and the blocked yield. If in the meantime a different thread invokes synchronize, it will be blocked until the first one finishes the block. Else if the same thread access the method in the meantime, it will not try to lock the semaphore again, but can yield its new block immediately.

Migrating to Cucumber

Today I migrated my simulation project to Cucumber. Until now I used rspec's plain text user stories.
The first part, migrating the rails application, was easy thanks to the good documentation in the wiki. The second part, the simulation server, was surprisingly easy as well. All I had to do was creating the same directory structure and following the same steps to move the files from stories to features as for the rails app. Then I removed all rails related lines from env.rb and added my init file, that loads all the classes for the simulation server.

require File.expand_path(File.dirname(__FILE__)+'/../../init')

# Comment out the next line if you don't want Cucumber Unicode support
require 'cucumber/formatter/unicode'

To run the stories I need to execute cucumber features/ in the corresponding direcotries. Running the rake features doesn't work for me as env.rb is not loaded.

Closures in Distributed Ruby

In this article I want to show how closures work with distributed ruby and what you have to do to make them work.
Here's a very simple server to start:

require 'drb'
 
class SimpleServer

 def initialize
   DRb.start_service('druby://localhost:9000', self)
 end
 
 def server_time
   Time.now
 end

end

SimpleServer.new
DRb.thread.join

In the constructor we start the drb service and register the server to localhost on port 9000. Then we have a very simple method, which just returns the time on the server, that we now want to call from our client. The last line prevents the programm to exit and keeps the server thread waiting for incoming requests.

require 'drb'

class SimpleClient 

 def initialize
   @remote = DRbObject.new(nil, 'druby://localhost:9000')
 end

 def time_on_server
   puts "Time on server #{@remote.server_time}"
 end

end

client = SimpleClient.new
client.time_on_server

In the client's constructor we get the remote object of the previous registered server. After that we can call the "time_on_server" method to print it on the client side.
Now let's add a method that uses a block parameter.
in the server:

  def time_on_client
    puts "Time on client #{yield}"
  end

and in the client:

  def client_time
    @remote.time_on_client { Time.now }
  end

Calling now "client_time" from the client, will raise a DRb::DRbServerNotFound error. The client fails to provide a drb proxy object for the server, which would need it to call the block on the client again. Blocks are bind to the environment, where they have been defined, in our case on the client.
All we have to do to make it work is starting also a drb service on the client side.

  def initialize
    DRb.start_service
    @remote = DRbObject.new(nil, 'druby://localhost:9000')
  end

So in Ruby we often have symetric roles, both sides need to act as client and server.

Szenario Greenfields

Die Lotka-Volterra-Gleichung beschreibt die Wechselwirkung von Räuber- und Beutepopulationen, wobei sich die Räuber- von der Beutepopulation ernährt. Interessant dabei ist, dass die gegenseitige Wechselwirkung der beiden Populationen das System stabil hält und sich dadurch selbst reguliert.

In meinem neusten Projekt, einer Simulation, habe ich dieses Szenario nachgebildet. Die Beutepopulation, bei mir einfach Resource genannt, hat im Gegensatz zur Obigen ein begrenztes Wachstum. Dadurch schwanken die beiden Populationen nicht mehr, in einer sinusförmigen Kurve, sondern stabilisieren sich auf einem Niveau.

Zudem wollte ich, die Resource auch unabhängig von der Population, meinen Räubern, simulieren können. Um dies zu erreichen musste ich die Resource von der Populationen entkoppeln. In meiner Simulation ist nur noch die Population an die Resource gekoppelt, hat aber auf diese Einfluss, indem sie sich von dieser ernährt und direkt deren Grösse ändert. Die Grösse der Resource auf der anderen Seite ist ausschlaggebend, wie viel Nahrung für die Population verfügbar ist und steuert damit deren Sterberate. Dadurch ist die Wechselwirkung wieder gegeben.

Dieses erste Szenario, das ich vorläufig Greenfields getauft habe, soll nun die Basis für verschiedene KI Agenten werden. Sie sollen die Populationen steuern und sich in diesem System zurechtfinden.

Reading Binary Files with Ruby

For my current project I need to read some binary data with Ruby. The data file is formatted as 16-bit BINARY INTEGERS, hi-byte-first order with 2160 x 4320 data values.

From my Java days I knew the DataInputStream class. With it it's every easy to read the data, just use io.readShort().
Therefore I was looking everywhere in IO and File for some methods to read the data in an appropriate format. But I couldn't find anything really useful as all methods are working with strings and characters.

But then I found the pack method in Array and its corresponding method unpack in String. With this two methods it's easy to read and write binary files in various formats.

Here the code snippet where I read the gzip compressed file. @size is in my case 4320 and @height an array of 2160. After reading the file I can access the data with @data[line][row].

Zlib::GzipReader.open(filename) do |gz|
  x = 0
  # read one line (16-Bit-Integer = 2 bytes)
  while line = gz.read(2 * @size) 
    @data[x] = line.unpack('s' * @size)
    x += 1
  end
end

If you need more, have a look at BitStruct. It provides a nice DSL for handling binaries.

Using multiple Ruby versions with Textmate

I have currently Ruby 1.8.6 and 1.9.1 on my machine. To test my libraries against both versions, it would be very convenient to switch between versions within your IDE . With Netbeans there's no problem as you can define different ruby environments (Tools/Ruby Platforms). In Textmate I couldn't find anything like that. But there's an easy way too: just define the path to your ruby version in the start script, just like you would do it for a shell script.

#!/usr/bin/ruby
puts RUBY_VERSION # => 1.8.6

#!/usr/local/bin/ruby1.9
puts RUBY_VERSION # => 1.9.1

2 Wochen CakePHP

Nach 2 Wochen arbeiten mit CakePHP hier eine kurze Bilanz. Im Grossen und Ganzen versucht CakePHP die Ideen und Konzepte von Rails zu übernehmen, was auch in vielen Teilen des Frameworks gelingt.
Der grösste Kompromiss den CakePHP einging, ist auf PHP4 statt gleich auf PHP5 zu setzten. Dies hat leider weitreichende Konsequenzen:

Das beginnt schont bei ganz einfachen Sachen, wie etwa dass CakePHP kein Exception Handling kennt. Stattdessen werden E_USER_WARININGs und dergleichen ausgelöst.

Der grösste Unterschied zu Rails besteht jedoch in der Implementierung von ActiveReocrd. Das AR-Objekt wird in erster Linie als SQL Generator eingesetzt, die 'find' und 'read' Mehtoden geben keine Objekte zurück, sondern tief verschachtelte Arrays. Die Implementierung von CakePHP erinnert daher mehr an ein Table Data Gateway Pattern. Auch in CakePHP kennt Active Record die bekannten Callbacks wie 'beforeSave', aber auch hier wird mit Arrays gearbeitet, nicht mit Objekten.
Eine weitere Konsequenz daraus ist das CakePHP kein Single Table Inheritance oder deren polymorphe Variante kennt.

Zusammendfassend lässt sich aus meinen ersten Erfahrungen sagen, dass das Erarbeiten von Business Domain Objects in CakePHP wesentlich schwieriger fällt als in Rails. Das Active Record von CakePHP ist darauf ausgerichtet aus der Datenbank zu lesen und schreiben und die gewonnen Daten gleich auszugeben. Die Business Logik sollte gemäss dem Motto 'fat model, skinny controller' in die Model-Objekte abwandern, dies ist aber genau die Schwierigkeit, wenn diese mehrheitlich nur als Arrays daher kommen.
Trotzdem ist CakePHP eine gute Alternative, wenn man an PHP gebunden ist (oder wird). Zudem bieten heute alle Provider PHP, wer für ein einfaches Projekt einen billigen Host braucht ist CakePHP sicherlich eine Option. Für komplexere Projekte lohnt sich Ruby zu erlernen und auf ein durchgehend objekt-orientiertes Framework wie Rails zu setzten.