ActionScript 3.0 Design Patterns

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?

Related posts:

1. Recorded Presentation on Parallel Programming and ActionScript 3.0
2. ActionScript 3.0 and Parallel Programming: Get Ready for Decomposition
3. ActionScript 3.0 Communication in Parallel Programming