ActionScript 3.0 Design Patterns

Parallel Tasks Branch in a Program Sequence

As noted in discussing Parallel Loops, you saw that the pattern applied a single operation to many data elements. With the Parallel Tasks pattern, you add a fork in the flow of control using distinct asynchronous operations that can run simultaneously. An analogous situation would be carpenters who saw and sand wood to prepare it for building a cabinet. The sawing and the sanding are two distinct tasks that can be completed simultaneously and asynchronously. Once both are complete, they can merge back to a single operation of fitting the cabinet together. At first, that sounded like a flow branch, but it’s not necessarily. In fact, it calls for a factory that each can be processed with. So, there’s a lot we can learn from the C#/.NET 4 implementation of parallel programming that we can use with ActionScript 3.0. To get started open up Parallel Programming with Microsoft .NET: Design Patterns for Decomposition and Coordination on Multicore Architectures to Chapter 3 (Parallel Tasks) or just click the //P Book button below:

The Task Factory

Fortunately for us, we have no Task class, System.Threading.Tasks namespace along with the static Task.Factory property with an instance of TaskFactory like C#. I say fortunately because that means we can make our own TaskFactory.

The //P Book provides us with the key ingredients:

1. Factory Method class
2. Product class (implied)
3. Task.Factory property
4. A forking method (StartNew)
5. A join method (Wait)

For this post, I want to concentrate only on using the forking and join methods. In a future post, we can look into the more general issue of parallel tasks, but for now I’d like to focus on the operations in ActionScript 3.0 for event dispatching and handling.

Do Fork

In order not to appear too obsessed with avoiding sequential programming, let me note that every method is usually nothing more than a sequence of statements and operations. When discussing the flow of control in a program, we often come to points where one object must be used before another can be used. In dealing with parallel tasks, the same issue comes up. Yes, it’s far more efficient to use separate cores to deal with different tasks concurrently, but that doesn’t mean that the tasks can be used as soon as they are completed. For example, in building a house, you can simultaneously build the foundation, four side and a roof, but they need to follow the sequence:

1. foundation
2. walls
3. roof

What we’re really dealing with is scheduling, and in ActionScirpt 3.0, scheduling can be handled by event dispatching. To get started, this post will handle a call to the event handler in a Join class. Without even working about the foundation and roof, this will begin with setting up the left and right walls. For now, we’ll assume that both walls will be handled, but even though both walls can be handled (built) simultaneously with two different cores, we have to put up the right wall first. As soon as a part is complete, it will dispatch a message to the Join class. This is still unfinished, but it provides a general idea of what we hope to accomplish. Figure 1 provides an overview:

Figure 1: Overview of Fork and Join

At this point, the Client requests a left and right wall from the Fork class. Each is created in a Factory and displayed. The problem is, that they have to be arranged so that the right wall appears first and then the left wall, no matter which order they are actually completed in. As soon as each is completed, it fires off the an event to see the sequence. In the next post, we’ll see about how to go about actually sequencing the parts, but for now, a trace statement will just remind us that the right wall has to be delivered first. You can see the download the files and run the example with the buttons below:

At this point you will see two walls appear simultaneously. The Fork class uses the event dispatched in the Join class to simulate a “Wait” event in sequencing. (Besides the wall, you will also get a trace() message about the sequence; no matter which wall is finished first.) It needs more work, but Parallel Tasks is better handled in small bites. This is the first bite (or byte…).
Read more…

Free //P Book
In looking at Parallel Loops as a design pattern in Parallel Programming with Microsoft .NET: Design Patterns for Decomposition and Coordination on Multicore Architectures, I found myself asking about the different participants. All that I could find were some relatively simple loops using the C# 4 format for parallel loops. (By the way, the parallel programming book is available free online –click //P Book button– if you’re interested—the upper left-hand corner of the page provides the links to all the chapters. Click on Parallel Loops to see what this post is based on.)

The Pattern that’s Easy to Understand

In thinking about parallel loops, I have no argument with their utility for speeding up application processing. (In this post, we have an ActionScript 3.0 game example.) Further, I found their explanation as to when to use the pattern to be clear:

Use the Parallel Loop pattern when you need to perform the same independent operation for each element of a collection or for a fixed number of iterations. The steps of a loop are independent if they don’t write to memory locations or files that are read by other steps.

You got two (or more) loops that have to be completed at roughly the same time, they’re not connected to each other directly, and so they won’t conflict. Why not run them in parallel? Makes perfect sense to do so. The chapter provides more details as when to use the Parallel Loops pattern, but the general explanation is done nicely.

However, after reading the chapter two thoughts crossed my mind:

1. Is this really a design pattern?
2. How would this look in ActionScript 3?

Let’s examine these two issues.

Where’s the Pattern?

In looking at Parallel Loops in C#, the examples show how to use the C#4 statements, Parallel.For and Parallel.ForEach. I wrote programs for each statement, but was at a loss to see where either statement was especially designed to enhance parallel programming as a pattern. Consider the following simple program in C#:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

using System;
using System.Threading.Tasks;
//Parallel For loop
namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            int n = 20;
            Parallel.For(0, n, k =>
            {
                Console.WriteLine(k);
            });
        }
    }
}

The results are sent to the screen via the console and can be seen in Figure 1:

Figure 1: Parallel For loop

As you can see, the output is non-sequential, but other than assuming that separate cores were involved in the processing, there’s only one loop processed. (This is an example I cooked up to illustrate how the Parallel.For loop works.) In the Chapter 2 example (which you can see in the online book), it is not clear what’s being processed. It appears as multiple accounts with multiple properties are being processed, but it’s about as clear as mud, and it’s equally unclear where the parallel loops are processed.

I had to ask, Are we really talking about Design Patterns or are these examples simply showing off C# multicore statements? It would be very helpful if their examples were better–you can’t just hand the reader an example and then run one with a sequential statement and the other with the parallel version of the same example, and say, “See! That’s a Parallel Loop!” Sheeeze!

Back to the question of are these really Design Patterns, and after spending a lot of time and head scratching, I believe they are. Essentially, what the chapter on Parallel Loops is doing is showing the //Loop as a general solution where multiple loops can be processed simultaneously. True, these patterns are different than the ones that GoF originally developed, and they are at a much lower level. There are no class diagrams, classes, interfaces or the collection of participants that we generally associate with design patterns. Rather, they are patterns that we can use when we have access to multiple cores. Ironically, while the issue of “What pattern is the most appropriate?” is equivocal to many DP programmers, that question appears to be a bit more self-obvious with the Parallel Loops. You’ve got two (or more) independent loops? Use the Parallel Loops pattern! That’s a lot easier than deciding whether to use a Visitor or Decorator pattern.

Love the Lambda! One of the features that I really like in the parallel for loop is the use of a lambda expression in the loop format. The segment, …Parallel.For(0, n, k =>… formats the loop with the starting value (0), the top value (n) and the increment (k) in a manner that is sweetly clear. If anyone at Adobe is listening, Put Lambda in the next version of ActionScript, please!.

Moving right along…

Parallel Loops in ActionScript 3.0

It took me about two seconds to come up with an example of where parallel loops would be handy in a Flash/Flex application. (It’ll probably take you even less time!) My example is from a combat game where two sides clash. After each fighting event, both sides have to count up their losses (to be subtracted) and resupply (to be added) to all.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

package
{
	import flash.display.Sprite;
	import flash.text.TextField;
 
	public class WarriorObjects extends Sprite
	{
		private var teal:Object=new Object();
		private var grape:Object=new Object();
		private var tealField:TextField=new TextField();
		private var grapeField:TextField=new TextField();
		public function WarriorObjects()
		{
			tealField.x=20,tealField.y=20;
			tealField.multiline=true;
			tealField.width=250, tealField.height=100;
			tealField.text="Teal Warrior \n";
			addChild(tealField);
 
			grapeField.x=20,grapeField.y=100;
			grapeField.multiline=true;
			grapeField.width=250, tealField.height=100;
			grapeField.text="Grape Warrior \n";
			addChild(grapeField);
 
			armTeal();
			getTeal();
			armGrape();
			getGrape();
		}
 
		private function armTeal():void
		{
			teal.ammo=10;
			teal.def=20;
			teal.mov=120;
			teal.weapon=30;
		}
 
		private function getTeal():void
		{
			var t:String;
			for(t in teal)
			{
				tealField.appendText("   "+t+": "+String(teal[t])+"\n");
			}
		}
		private function armGrape():void
		{
			grape.ammo=15;
			grape.def=20;
			grape.mov=150;
			grape.weapon=20;
		}
 
		private function getGrape():void
		{
			var g:String;
			for(g in grape)
			{
				grapeField.appendText("   "+g+": "+String(grape[g])+"\n");
			}
		}
	}
}

In this simple illustration, the “Teal” and “Grape” warriors are armed and then using a for..in loop, both sides are evaluated using two functions, getTeal() and getGrape(). Those two loops can be run simultaneously after each clash. The mechanics of working out what values are added to or subtracted from each warrior on each side involves arrays and an algorithm for determining whether points are added to or subtracted from the warriors.

Imagine in a game simulation where all of the warriors on both sides can be quickly prepared for the next round because each can be separately but simultaneously evaluated in parallel loops each using a separate core. The larger and more complex the game, the more valuable this kind of concurrent looping would be.

Feedback Please

You’ve got access to the same book about //P that we do and we’d like to hear from you. Can and should ActionScript adopt some of the C# .NET structures for multicore programming such as Parallel.For and Parallel.ForEach? From the Adobe side, I’ve heard rumors of using Master-Worker models from //P, and that certainly is an interesting approach. What do you think?

Parallel Loops

The first //P Design Pattern in the Parallel Programming with Microsoft.NET: Design Patterns for Decomposition and Coordination on Multicore Architectures (or //P_DP book) is something they call Parallel Loops. After reading the chapter it was clear that I needed programming access to at least two real cores. In past posts I’ve used interleaving with threads, but for the Parallel Loops pattern, I had to address two separate cores.

Taking inspiration from that famous engineer/artist Rube Goldberg, I devised a two-core access contraption that I could use as a way to either run two independent loops on two different cores or split a larger loopable object (if you haven’t heard of a loopable object; now you have) into two parts for concurrent processing.

Excuse my Single Class

Here are the parts of my multi-core access class:

1. Flash/Flash Builder working with ActionScript 3.0 (on my client computer)
2. Flash Media Server access from the same class (on a separate computer) but accessible via ActionScript 3.0 with ActionScript 1.0 on FMS

Doing the same thing with Cold Fusion or PHP would work as well, but using FMS, you can use ActionScript for both cores. Of course, with FMS, all of the ActionScript is AS1 (almost identical to JavaScript); so there’re some differences.

The code for the class is a little hacky, and eventually I want to improve it and make it more interactive as well as provide the user with more options. I built it using Flash Builder. Basically, all the class had to do was to do loops that could be run from one of two cores—local client or FMS server. Also, since some of you might want to fiddle with it, I provided an RTMP address you can use to test it yourself. The following shows the class and code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

package
{
	import flash.display.Sprite;
	import flash.events.NetStatusEvent;
	import flash.net.NetConnection;
	import flash.net.Responder;
	import flash.text.TextField;
 
	public class ParallelWork extends Sprite
	{
		private var nc:NetConnection;
		private var showCore1:TextField=new TextField();
		private var showCore2:TextField=new TextField();
		private var responder:Responder;
		private var infoCode:String;
		private var rtmpNow:String;
		private var pp:uint;
		public function ParallelWork()
		{
			//rtmpNow="rtmp://192.168.1.43/parallel";
			rtmpNow="rtmp://poobah.mwd.hartford.edu/parallel";
 
			nc=new NetConnection;
			nc.connect (rtmpNow);
			nc.addEventListener (NetStatusEvent.NET_STATUS,confirmConnect);
			addChild(showCore1);
			addChild(showCore2);
		}
 
		private function confirmConnect(e:NetStatusEvent):void
		{
			infoCode=e.info.code;
			if (e.info.code=="NetConnection.Connect.Success")
			{
				showCore1.width=350;
				showCore1.text=infoCode;
				showCore2.width=350;
				showCore2.y=100;
				showCore2.text=infoCode;
				getCore1(1,499000);
				getCore2(500000,1000000);
			}
			else
			{
				showCore1.text=infoCode.substring(22);
			}
		}
 
		private function getCore1(bN:uint,eN:uint):void
		{
			var cB:Number;
			var cE:Number;
			var pN:Number;
 
			for(pp=bN;pp<eN;pp++)
			{
				cB=bN*Math.PI;
				cE=eN*Math.PI;
				pN=pp*Math.PI;
			}
			showCore1.text="Core1: Begin: " + cB + " End: " + cE;
		}
 
		private function getCore2(bN:uint,eN:uint):void
		{
			responder=new Responder(parallelResponse);
			nc.call("parallelOn",responder,bN,eN);
		}
 
		private function parallelResponse(parallelInfo:String):void
		{
			showCore2.text=parallelInfo;
		}
	}
}

You can experiment with the class using the getCore2() method. The first parameter is the starting point of a loop and the second parameter is the ending point. You can set the getCore1() method the same way. The only difference is that getCore1() runs on a local core and getCore2() runs on the remote server’s processor. However, you really do get two different cores.

The server-side (FMS) code is super-simple, and just works out the circumference for a set of values sent from the client side. Unless you have access to FMS or want to download a developer’s version to your local computer, the only thing you can do with it is to test doing loops with multiple cores. The Core 2 processors loops through the beginning and ending values sent to it by the ParallelWork class on the client-side and multiplies each iteration by Math.PI. The way the current example is set up, the code breaks a one million iteration loop into two 500 thousand iteration loops. Each half of the loop is handled independently, as is an important feature of the Parallel Loop design pattern.

In case you want to do some FMS on your own; here’s the FMS (client-side) ActionScript. Keep in mind that it is weakly typed and does not understand data types.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

application.onConnect = function(client)
{
 	application.acceptConnection(client);
	trace("parallel connected");
 
	client.parallelOn = function(bN,eN)
	{
 
//This section represents a loop governor placed on my account
//If you have your own or access to a different FMS, you can remove it.
//-------------------------------------------------------
                //Loop governor
	        if(bN>2000000)
	        {
		        bN=2000000;
	        }
	        if(eN>2000000)
	        {
		         eN=2000000;
	         }
//-------------------------------------------------------
		var pp;
		for(pp=bN;pp<eN;pp++)
		{
			var cB;
			var cE;
			var pN;
			cB=bN*Math.PI;
			cE=eN*Math.PI;
			pN=pp * Math.PI;
		}
		 client.parallelInfo="Core2: Begin: "+ cB + " End: " +cE;
		return client.parallelInfo;
	};
}

Click the Play button to give it a whirl and the Download button to retrieve the code:

What you should see is the following:

Core1: Begin: 3.141592653589793 End: 1567654.7341413067
Core2: Begin: 1570796.3267948965 End: 3141592.653589793

You will see Core 1 first, a delay and then Core 2. The delay for Core 2 depends on whether the FMS server has a lot of traffic at the time you give it a run.

Shouldn’t It Be Faster With Two Cores?

If both cores were on the same computer and processing unit, it’d be a lot faster. Further, if one of the cores wasn’t running AS1 on FMS, it’d be faster. However, the purpose of this gizmo is to practice working with dual cores, and the only way (that I know of) to do that right now with ActionScript 3.0 is to use an external accessible program using a different core. I know that Molehill and Pixel Bender have hooks to multiple cores, but I’ll have to keep looking to find those hooks. However, in seeking ways to understand the emerging design patterns for parallel programming with ActionScript 3.0 is to build some kind of testing contraption (objecto) to run ActionScript processes on different cores. This particular one is to test the Parallel Loops design pattern described in //P_DP book. My Neuerfindung is just a modeling and testing tool.

To the end of devising an aggeggio for accessing multiple cores with ActionScript, I welcome any comments for improvements on what I’ve built. If any of you have a program that can do that (not just a link!) please send it in, and if we can use it we will.

In the meantime, take a look at the Parallel Loops pattern, and let’s share ideas about how it can be implemented in ActionScript 3.0. I realize that lots of this is emergent, but the beginning is also the most fun.

Next week, I’d like to really focus on the Parallel Loops pattern and try and provide an example that actually works with ActionScript. And remember, we’re always looking for better ways to accomplish the goal of understanding; so don’t be shy, suggest some ideas—send the working example with the idea, though!