Wednesday, 31 August 2011

Sidestepping Immutability

A requirement of the Actor model in Fantom is that any instance variables are constant and immutable. There is a workaround, which is 'sys::Unsafe': this is a wrapper class, which tells anyone that asks that it is immutable. To use, you simply pass the object you want wrapped in its constructor, and use 'val' (and a cast) to retrieve the value.

Here's a little 'fansh' session to illustrate:

Fantom Shell v1.0.59 ('?' for help)
fansh> a := [1,2,3]
[1, 2, 3]
fansh> a.isImmutable
false
fansh> b := Unsafe (a)
fan.sys.Unsafe@406199
fansh> b.isImmutable
true
fansh> b.val
[1, 2, 3]
fansh> (b.val as List).add (4)
[1, 2, 3, 4]
fansh> b.val
[1, 2, 3, 4]

We can see that 'b' holds a reference to the list, and can even be asked to update the value of the list, but reports to the outside world that it is immutable.

Unsafe Worker

We can use Unsafe to provide the equivalent of mutable instance variables in the Worker class I used in my last post. Below is the complete code for the same example, but now using Unsafe references instead of Actor.locals.

Apart from the cast needed on lines 45 and 50, this now looks more like the SwingWorker example, using instance variables to hold references to the GUI widgets. We can now even refer to the GUI widgets in the 'receive' method, which we could not do using the Actor.locals method: see line 33.

01: using concurrent
02: using fwt
03: 
04: class Calculate
05: {
06:   static Int fib (Int n)
07:   {
08:     if (n < 2)
09:       return 1
10:     else
11:       return (fib (n-2) + fib (n-1))
12:   }
13: }
14: 
15: const class Worker : Actor
16: {
17:   const Unsafe result
18:   const Unsafe button
19: 
20:   new make (Unsafe result, Unsafe button) : super (ActorPool ())
21:   {
22:     this.result = result
23:     this.button = button
24:   }
25: 
26:   override Obj? receive (Obj? msg)
27:   {
28:     // we only care about one message - a number to compute from
29:     n := msg as Int
30:     if (n != null)
31:     {
32:       // we can access our Unsafe variables here!
33:       Desktop.callAsync |->| { (button.val as Button).text = "working!" }
34:       // do the actual computation
35:       startTime := DateTime.now
36:       res := Calculate.fib (n)
37:       // call the 'update' method on the GUI thread
38:       Desktop.callAsync |->| { update(n, res, DateTime.now - startTime) }
39:     }
40:     return null
41:   }
42: 
43:   Void update (Int n, Int res, Duration time)
44:   {
45:     (result.val as Label).with 
46:     {
47:       text = "Fib($n) = $res in $time"
48:       pack
49:     }
50:     (button.val as Button).with
51:     {
52:       text = "compute"
53:       enabled = true
54:       pack
55:     }
56:   }
57: }
58: 
59: class Main
60: {
61:   static Void main ()
62:   {
63:     chooseN := Text { text = "1" }
64:     result := Label ()
65:     button := Button { text = "compute" }
66:     button.onAction.add |Event e|
67:     { // when button clicked
68:       button.with
69:       {
70:         text = "Busy"
71:         enabled = false
72:       }
73:       Worker(Unsafe(result), Unsafe(button)).send (chooseN.text.toInt)
74:     }
75: 
76:     Window
77:     {
78:       title = "Fibonacci"
79:       GridPane // place widgets in a column
80:       {
81:         chooseN,
82:         button,
83:         result,
84:       },
85:     }.open
86:   }
87: }
88: 
89: 

Monday, 29 August 2011

Fibonacci Program using an Actor

In this post, I rewrite my Swing-based fibonacci program using the Fantom Widget Toolkit and an Actor. Fantom uses Actors to manage concurrency. There are a number of conceptual challenges when starting to use Actors, and some of this is a consequence of the requirement for Actors and the objects they manipulate to be immutable. For an Actor to be immutable, it must not contain any instance variables which are mutable. Hence, Actors cannot themselves store mutable state.

Instead of instance variables, a special Map, called Actor.locals, is used to store mutable objects. However, Actor.locals cannot be thought of as an equivalent to instance variables for the current Actor: Actor.locals are local to a particular thread.

Actors are triggered into action on receipt of a message. When sent a message, the runtime generates a thread for the Actor to do its work - thus, the Actor will not necessarily be running in the same thread for every message. This is why Actor.locals, which is tied to a thread, cannot be used to store intermediate results between messages.

The only thread (in an FWT application) which is guaranteed to be working and retrievable is the GUI event thread. The method Desktop.callAsync is used to call a provided function on the GUI event thread.

We can use an Actor to implement the equivalent of SwingWorker by sending the Actor a message to trigger it to do its work; rather like the doInBackground method of a SwingWorker which is started on calling execute. The Actor can then, when finished, call a method in the GUI event thread, rather like the done method of a SwingWorker is invoked on the event thread.

FWT Fibonacci Application

01: using concurrent
02: using fwt
03: 
04: class Calculate
05: {
06:   native static Int fib (Int n)
07: }
08: 
09: const class Worker : Actor
10: {
11:   // in constructor, place widgets we need to access in GUI update
12:   // within Actor.locals
13:   new make (Label result, Button button) : super (ActorPool ())
14:   {
15:     Actor.locals["result"] = result
16:     Actor.locals["button"] = button
17:   }
18: 
19:   // receive any messages sent to this worker
20:   // Note: Actor.locals *not* accessible here!
21:   // so any information for calculation must be included with message
22:   override Obj? receive (Obj? msg)
23:   {
24:     // we only care about one message - a number to compute from
25:     n := msg as Int
26:     if (n != null)
27:     {
28:       // do the actual computation
29:       startTime := DateTime.now
30:       res := Calculate.fib (n)
31:       // call the 'update' method on the GUI thread
32:       Desktop.callAsync |->| { update(n, res, DateTime.now - startTime) }
33:     }
34:     return null
35:   }
36: 
37:   // this method called in GUI thread to update GUI widgets
38:   // note: Actor.locals from constructor is accessible here
39:   Void update (Int n, Int res, Duration time)
40:   {
41:     // retrieve result from Actor.locals, and update it
42:     result := Actor.locals["result"] as Label
43:     result?.with // use safe invoke, just in case 'result' is null
44:     {
45:       text = "Fib($n) = $res in $time"
46:       pack
47:     }
48:     // retrieve button from Actor.locals, and update it
49:     button := Actor.locals["button"] as Button
50:     button?.with
51:     {
52:       text = "compute"
53:       enabled = true
54:       pack
55:     }
56:   }
57: }
58: 
59: class Main
60: {
61:   static Void main ()
62:   {
63:     chooseN := Text { text = "1" }
64:     result := Label ()
65:     button := Button { text = "compute" }
66:     button.onAction.add |Event e|
67:     { // when button clicked
68:       button.with
69:       {
70:         text = "Busy"
71:         enabled = false
72:       }
73:       Worker(result, button).send (chooseN.text.toInt)
74:     }
75: 
76:     Window
77:     {
78:       title = "Fibonacci"
79:       GridPane // place widgets in a column
80:       {
81:         chooseN,
82:         button,
83:         result,
84:       },
85:     }.open
86:   }
87: }
88: 
89: 

In line 73 of the code, we create the Worker object, passing it references to the results label and button; these are stored in the Actor.locals map in lines 15 and 16.

In line 73, we also send a message to the Worker: this message is just a number. We receive that message in the 'receive' method at line 22. This method is responsible for responding to all messages that the Worker may receive, and so it must first check that the message is a number; this is done in lines 25 and 26.

Lines 29 and 30 perform the computation, and this is in a background thread, so does not interfere with the GUI event loop.

Line 32 then calls the 'update' method on the GUI event loop, so the graphical displays can be updated with the result.

Line 42 retrieves the 'result' widget from the Actor.locals store, and lines 43 onwards perform the update on that widget. As it is possible the 'result' widget is not in the store, we should take care in case 'result' has been set to 'null'; in line 43 we use the safe invoke operator '?.', which will only call the succeeding method if the instance is not null.

When first trying to understand Actors, it is easy to get confused about what can be retrieved from Actor.locals and when. In this program, the widget values in the Actor.locals map are only retrievable when the Worker is running in the GUI thread. If you try a check for Actor.locals["result"] in the 'receive' method (say at line 24), you will get the result 'null'.

Comparison with Swing version

When put side-by-side, there is not much difference between the Worker class implemented using an Actor and the Worker class using SwingWorker. In both cases, the constructor is passed the GUI widgets, and in both cases these widgets are updated in a separate method guaranteed to be run in the GUI thread. The Actor implementation means the stored widgets must be retrieved from Actor locals, but the null-safe invocation of the with-clause means there is no need to check if the widget has been successfully retrieved.