ActionScript 3.0 Design Patterns

Communication in a Parallel Environment

This week I decided to do one post for beginners and one for those of you interested in parallel programming and was able to use a simple program for both. The program is one with a client that communicates through a single abstract class requesting house parts in the form of Shape instances. Not a true design pattern, but no matter; it illustrates OOP communication and parallel decomposition.

Since I got tired of writing out “parallel programming” I decided to use the following symbol–//P–as a shorthand. The two slashes reminded me of two sides of a parallelogram and the P is…well for “Programming.” It’s handy, short, and easy to remember.

Having been thinking about decomposition in parallel programming, I thought that it might be interesting to use the beginner’s communication example to first illustrate decomposition. The program I used calls up four house shapes—a wall, a roof, a door and a window. It then assembles then one the screen. (Take a look at the previous post to see the program.)

The Client has methods that calls each of four Shape instances from an IShapeCity concrete implementation and then arranges them in a Sprite object. The four shapes are very inexpensive and the entire process appears as though the house appears in one fell swoop instead of in a sequence of four operations. However, suppose that instead of four very inexpensive operations, the application was made up of four very expensive ones but followed the same process. Further, instead of using a single core, the process was decomposed into four tasks. Further, each task was assigned a single core. The following little Flash movie shows the process (click Replay):
[swfobj src="http://www.as3dp.com/wp-content/uploads/2011/04/QuadHouse.swf" align="none"]

I’ve been wading through Parallel Programming with Microsoft.NET: Design Patterns for Decomposition and Coordination on Multicore Architectures by Colin Campbell, Ralph Johnson, Ade Miller and Stephen Toub. (I’m going to summarize that mouthful too—the book will be //P DP and the authors the Quad Core or just 4C.) The process, according to the authors, is called parallelizing, and it refers to taking a program designed for single core computations and decomposing it for //P. In fact, the entire process of designing for //P involves only three key operations:

1. Decomposing the work into discrete units know as tasks
2. Coordinating these tasks as they run in parallel
3. Sharing the data so that the solution is scalable.

Naturally, it’s not that easy. Not by a long shot.

Can It Scale?

The 4C warn about parallelizing a single core program by simply looking for hotspots and give each a core. That’s what was done above. Assuming that the house parts are each very expensive (involve lots of processing), it makes sense on one level to do exactly that—find the expensive tasks and assign each one a core. I suppose that the decomposition process can be relatively easy using that approach. Besides, that allows the developer to keep the current structure using the same design patterns created for single core programming.

First of all, that approach doesn’t bode well for any program run on a single or dual core chip. It’ll be looking for additional cores that just aren’t there. The Quad Four suggest that programs be developed for single cores but have the ability to run on multiple cores. Any programming language that has access to multiple cores in the language has to have some way of knowing the number of cores are available for processing. Second of all, what happens to a program that decomposed to a certain number of task when it gets new tasks. For instance, the house has four tasks—build a wall, a roof, a door and a window. What happens when you decide to add a chimney?

Scaling has at least two dimensions—scaling to the hardware and scaling to the program development. If the program doesn’t do both, you’ll have problems down the road. It’s bad enough when you have to re-write a program for single core programming because you made some changes. However, imagine having to rewrite all of your programs every time a computer manufacturer uses a different chip. Most of the programs I have will run on my single core Pentium box, my dual-core laptop or my quad-core I have in my office at work. I realize that those programs do not handle processing, but since that’s what is going to be the future of program development and scale, it’s an important consideration.

Coordination is Communication

The second key issue in //P development is coordination of tasks. Here, I just wanted to throw out some issues that I’m hoping you’ll comment on. Later on, I’d like to devote a post or two to the coordination issue in //P for a little more in-depth consideration.

Up until now, coordination in programming has been isolated in a sequence along a single core. A hint of what the future holds in coordination can be found in work with databases and multi-server processing like Flash Media Server (FMS). The server-side and client-side processing does involve multiple processors, and what’s more, you can address them independently. For example, in FMS, you can send a job to be handled by the server-side code (play a video) and then let you know when that video is ended so that you can do something else in the program on the client-side. The event-notices that the server side code sends between client and server-side processors help coordinate program flow.

If any beginners are happening to be reading this, it underscores the importance of understanding that OOP programming is really about communication, and communication is the key to coordination. For those of you veterans who have toiled in the fields of OOP and design patterns for years, it’s another challenge. It’s one thing to change programming behavior from procedural to OOP and to begin building abstract structures like design patterns to increase programming effectiveness, but with the introduction of //P, the landscape has changed in another direction. The solutions that are emerging seemed to have bubbled up from the hardware folks, and while I like wire monkeys as much as the next guy, I’m not sure that their modeling is what software developers need. In snailing through //P DP, I see some of the same understanding for the need for abstraction as can be found in GoF, but then I see solutions that have a hardware origin and get nervous. The solutions have to be more than asking,

Is the hardware ready?

Your comments are welcomed.

OOP & Parallel Programs Depend on Communication

Before we get going, one of the areas I’ve spent a good deal of my ActionScript time with is Flash Media Server (FMS). There’s lots of communications between client-side and server-side objects in FMS, but that kind of communication, I’m side-stepping, at least for now. The focal point of this post in inter-class (or inter-object) communications and not server-server or client-server communication.

What Does it Mean to Communicate in ActionScript 3.0?

In this discussion, I want to talk about objects (instances of classes) communicating with other objects. However, even before that discussion begins, we can think of a very easy type of communication that is usually intra-object—event handling. Consider the following snippet:

1
2
3
4
5
6

upBtn.addEventListener(MouseEvent.CLICK, doUp);
....
private function doUp(e:MouseEvent):void
{
	contextNow.upMove();
}

The event is a mouse click, and when that event is communicated, it fires off a function that in turn communicates through a context interface to launch a method which in turn will communicate with a concrete state object to move a movie clip in an upward direction. (This is from an Aid Game in a previous post.) So the very first kind of communication that you probably already know about is that action taken when an event occurs that communicates with a method to do something. In the example snippet above, CLICK event set off a chain reaction in a State design pattern that communicated throughout the pattern with the ultimate communication telling a movie clip to lower its y value making it move upward on the screen.

Another place where you can find good examples of communication is in the chapter and posts that Chandima and I have on the Model-View-Controller. In Chapter 12 on page 428, you’ll find and excellent discussion of communication in the MVC that Chandima wrote. Also, on page 445, you can see an example of how an EventDispatcher is employed in the MVC. Chandima’s post on the MVC shows how the elements that make up the MVC communicate using the EventDispatcher. In my MVC post, the EventDispatcher is in the Model class. The EventDispatcher is a good place to look to see how messages are sent and received. They trigger and are triggered by different states, but the actual “message” that is passed is either a Boolean or a value from another property or operation.

How Do Objects “Talk?”

In the context of design patterns, objects communicating with one another is relatively easy to understand conceptually since all patterns are made up of more than one objects, and they must communicate to function together. In order to show a simple Client-request model works I made a little application that has a single abstract class and four concrete classes. Figure 1 shows the class diagram of app (that is not a design pattern.)

Figure 1: Client communicating through abstract class to concrete classes

The following identifies some of the key types of communication:

1. object initialization
2. method parameters
3. a return statement
4. event listening
5. while loops (awaiting a state)

The two main forms of communication entail using data from other objects and waiting for an event message. There are probably more I haven’t thought of, and they do depend on context; so if you can think of other communication statements, conditions or contexts, send in a comment with an ActionScript 3.0 example.

The essence of OOP is communication. Once you understand that, your programming will get better. It will be better organized, and you can re-use code. It may not be faster or process more data at one time. If you want speed, learn assembly language. Nothing beats it for speed. It just take about ten times as long to write, and even longer to learn and debug.
Read more…

Decomposing a solution for multicore processing

I’ve been looking at a lot of materials on parallel programming attempting to sort out the issues involved. One of the big issues is granularity, and not only does granularity affect the way we think about design patterns, it also impacts algorithms. To make matters even more interesting, granularity is affected by the number of cores your computer has, and so not only is it important to consider the level of granularity for a general level of programming efficiency, it’s also important to consider the hardware.

I don’t want to re-visit the issue of first learning OOP and Design Patterns to get away from concerns of tweaking algorithms and extracting the last electron of speed, but let’s face it, not only are we tossed back into the algorithm business, but we’re programming down to the metal. So even if Adobe came along tomorrow and told us, ActionScript 3.0 is now totally hooked into multicore access, it’d be a while before we could spool up to the point where we could be anywhere near as efficient as we are now with single core programming. In some respects, Adobe has saved our bacon because while it’s getting ready to provide parallel programming for ActionScript, we have time to learn how to think about using multiple cores.

The Free Ride is Over

Sometimes a phrase is uttered and at some level I understand it, but I really don’t appreciate it.

Last year in a video on parallel programming, Ralph Johnson said, ‘The free ride is over’ and now I get it.

Learning OOP and design patterns has come close to guaranteeing that once you mastered them, your programs would become increasingly more effective (in getting them done and revised), more available to re-use, and for participation in team projects. They would also become more efficient over time because Moore’s law was hard at work doubling processor capability every two years or so. Using OOP and design patterns helped us effectively organize our code into neat programs and we didn’t have to think too much about algorithms and certainly not our processor. Programming had become wholly divorced from the hardware—along with the OS and brand and clock-speeds. Those things took care of themselves. That was the “free ride”—no changes in our programming behavior.

Now, we have to think about things like the number of cores in our stupid processors. Let’s hope we don’t have to worry too much about OOP and design patterns—if they stay relatively stable, we can now begin to focus on these multiple cores. The free ride is indeed over.

Granularity

The last time I thought about granularity, I was thinking about the number of child classes in a design pattern. That’s not what granularity is in parallel programming.

In parallel computing, granularity is a qualitative measure of the ratio of computation to communication. Blaise Barney, Lawrence Livermore National Laboratory

Fortunately, we’ve been using OOP, and so are clear on the concept of communication between objects. (If you’re still doing sequential programming, bump up to OOP, quick!) What the conversation is about the time that your processor(s) is working through an algorithm or data processing and the amount of time it’s communicating to the other objects about the computations. The polar types are:

1. Coarse: relatively large amounts of computational work are done between communication events
2. Fine: relatively small amounts of computational work are done between communication events

We need to begin this conversation. How coarse or fine should a program be? What criteria do we use? Is there a handy formula? Just leave OOP and design patterns alone for the time being. Treat them as immutable but essential; later on we can start tweaking them for parallel programming.

Domain Decomposition

Since we don’t have to think about what actually happens to our program—it’ll be handled by the OS and we cannot direct threads to cores anyway. We can pretend to do so, and that’s all that counts right now. In the next post on parallel programming (and on subsequent ones) I’d like to write some programs in ActionScript 3.0 that illustrate domain decomposition as a first step. This will involve taking a process and breaking it down into smaller parts and processing each one separately, and then joining the results. Not only will this be an example of targeting multiple cores, but it is a very clear illustration of what computational and communication processes look like. In the meantime, think about the new kind of thinking required to optimize a program where using more than a single processor is the only way to improve performance—the end of the free ride.

Interleaving Threads are like Alternate Hammer Strikes

With access to a single processor, any green threads need to take into account interleaving. This post provides a demonstration of using interleaving with a Factory Method pattern. Basically, interleaving refers to two threads being processed simultaneously. One part of a thread is processed, and then a part of another thread is processed. The simplest way to do this with ActionScript 3.0 is to use a Timer class. Ideally, the two threads are processed on separate cores of a multi-core processor. (Adobe PhotoShop uses multiple cores through pixel bending; so there’s hope that we might be able to figure out a way to work this example into a way to use multiple processors for multiple threads—true parallel programming.) The Timer object has two parameters, delay and repeat:

Timer(delay, repeat);

Between the repeats and delay, each thread segment takes a “turn.”

Think of it as two men working with sledge hammers taking alternating hammer blows on a railroad spike. When one lifts his hammer, the other is striking downwards, and vice versa.

Usually, demonstrations of this kind of multithreaded process are illustrated with counter loops. However, the point is to show “expensive” processes, and so I decided to make the counters with graphic PNG squares numbered from 0-9. A counter display consists of 4-digits. Each graphic image had to be loaded and displayed as it was called by a timed, interleaved Timer objects. Because of the delay in the Timer object, it was possible to slip in the two “threads” and watch as the two counters simultaneously displayed the numbers. Also, the expensive counter slowed the process enough so that you can see the simultaneous counting “threads.” Click the play button to see the results and the download to see all of the class code:

My thoughts have been that if we can work out a way to simulate multithreaded programming, we’ll better appreciate what’s going on and start writing code for multi-core processors. Naturally, all of us would rather see ActionScript 3.0 classes where we could create multiple threads with the knowledge that those threads would be sent to separate cores for processing. I have a lot of faith that this will come because of the momentum that concurrent programming has generated.

So What About Design Patterns?

You may be asking yourself,

What can I do with all of those design patterns I learned? How can they be used with multithreaded programming?

Not to worry. Knowing design patterns is helpful in visualizing multiple threads and programming to them. For the example here, I used a Factory Method (again) because it is a clear way to visualize the process of multithreaded programming. Figure 1 illustrates the two threads concurrently but separately instantiating the two product objects. (The abstract classes and factories are assumed—just the threads directly to the products are shown for the purposes of illustration.)

Figure 1: Visualizing multithreaded process in Factory Method Pattern

So the question really is how to set up interleaving to generate multiple threads. I looked at different examples, and most of them showed some kind of timing—either with the Timer class or nested loops. Nested loops give me the creeps;so I decided on using the Client to take care of the interleaving by making alternating timed requests to two different products. The following listing (next page) shows the code for the Client making requests through the Factory Method design pattern:
Read more…

This post is one that I can easily reference for beginners in OOP and Design Patterns when writing the posts for the Beginners Series. For many, including beginners, it may be too basic, but just in case a developer interested in taking the OOP route is unfamiliar with programming ActionScript 3.0 off the Timeline in Flash Professional or away from a Flex Project in Flash Builder, this will be a quick starting point to take the road less traveled in OOP and Design Patterns. (The instructions for getting started with Flash Builder are a bit long. However, you’ll find the instructions for getting started with Flash Pro following them.)

Starting An ActionScript 3.0 Project in Flash Builder

As far as this series is concerned, the focus will be on creating objects and design patterns in ActionScript 3.0 using an ActionScript Project in Flash Builder and adding ActionScript classes and interfaces. At some point, we may introduce some Flex features, but you’re better off getting a good Flex book and working with it.

Step 1: Open an ActionScript Project

Select File > New > ActionScript Project from the menu bar. Figure 1 shows what you will see:

Figure 1: Select ActionScirpt Project in Flash Builder

Step 2: Name Your Project

As soon as you select ActionScript Project, a New ActionScript Project window appears. In the Project name: box type in the name of your project. Figure 2 shows that the name “BeginOOP” is used.

Figure 2: Adding a Project name

Step 3: Click Next (see Figure 2) and add a Client name

When you click the Next button, you’ll see the second step in creating an ActionScript project. Here is where you provide a name for the main class in the project. Since we’ll be working with design patterns, you’ll soon learn that the requesting class is named Client; so you’re likely to see “Client” used as the main project class. (See this Simple Explanation as to why the name Client is preferred.) The default name for the class is the project name; so you’ll have to change it as shown in Figure 3.
Read more…

A Stack is More than the Sum of its parts

The very first thing to learn about OOP and Design Patterns is that they were not intended to optimize program speed or even efficiency. They were developed to increase programmer efficiency and cut back on wasteful wheel re-invention. They help organize your code so that you can accomplish more and not spend as much time unraveling poorly organized code, work better with teams on large-scale projects and re-use program parts on new programs.

If you’re thinking,

Well that’s a step backwards…

think again. Early coding was done by setting switches, then moved up to microcoding (1′s and 0′s representing switch settings), then to machine language, on to assembly language and finally up to higher level languages like Fortran and eventually to Java and ActionScript 3.0 (with lots of half-steps and side-steps in between.) Each step added more “overhead” to the code which reduced efficiency. If you really want “efficient code” you’d better become acquainted with assembly language. You write programs using opcodes to work directly with the processor and memory. (Who can ever forget that LDA means load the accumulator? Lots of people can forget it!)

Reality Sui Generis

When you think of a key word like trace(), if, for or any number of other ActionScript 3.0 terms, you probably don’t think that those statements are really a combination of other instructions (coded operations). That’s good that you don’t think in terms of 0s and 1s when you’re programming. ActionScript 3.0 words make something happen. If you string them together in programming logic, more stuff happens.

Because you know that the instructions in ActionScript 3.0 are really lower level instructions bound together, if you begin to think of objects in OOP programming in the same way that you do keywords in ActionScript you can begin to see how objects are “things” just as keywords are things. For example, the following script (in the Actions panel in Flash Pro) creates a circle and places it on the screen. You can see that it takes six lines of code to make it work:

1
2
3
4
5
6

var myOrb:Shape=new Shape();
myOrb.graphics.beginFill(0xcc0000);
myOrb.graphics.lineStyle(4, 0x0000cc);
myOrb.graphics.drawCircle(200,200,100);
myOrb.graphics.endFill();
addChild(myOrb);

Your Actions panel needs a proper burial, right next to Ralph, your departed pet goldfish

Next, if we take the same code for creating the circle (all 6 lines), we can turn it into a “thing”—an object. However, just like you don’t think of trace() as a bunch of commands you cannot see, the object you’re creating with the 6 lines of code is a reality sui generis—an entity in and of itself. It has characteristics of a “Circle” object just like a “Haystack” object has different characteristics not understood by the individual straws. (Think of “roll in the hay” and a “roll on the straw” and you’ll see what I mean.)

From Lines of Code to Objects

Beginning with the 6 lines of code to create an object, we’ll use the following steps:

1. Open a new ActionScript 3.0 Class File
2. Add the following code and save the file as Circle.as

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

package
{
	import flash.display.Sprite;
	import flash.display.Shape;
 
	//The class is the object
	//By extending another class, it gets all of the properties
	//and methods of the other object (class).
	public class Circle extends Sprite
	{
		//This is a property of the object
		//Private properties are encapsulated
		private var myOrb:Shape=new Shape();
 
		public function Circle()
		{
			doCircle(0xcc0000,0x0000cc,200,200,3,100);
		}
 
		//This is a method
		//Private methods are encapsulated
		private function doCircle(fc:uint, bc:uint,ex:Number,why:Number,bw:uint,radius:Number)
		{
			myOrb.graphics.beginFill(fc);
			myOrb.graphics.lineStyle(bw, bc);
			myOrb.graphics.drawCircle(ex,why,radius);
			myOrb.graphics.endFill();
			addChild(myOrb);
		}
	}
}

As you can see in the function doCircle() we only used 5 of the original 6 lines. That’s because the first line was declared a private variable and instantiated outside of the function. When a function is part of a class, it is known as a method. The private variable, myOrb, is a property of the class. Both are private meaning that they can only be accessed from within the class. Another way of putting it is that they are encapsulated.

If you think about it as a way of making all of that code a single “thing” in the same way that the trace() statement is a single “thing” the concept of encapsulation makes more sense. Suppose we ran a trace() statement and something unexpected happened. It was affected by some outside influence that somehow had access to the trace() statement. By encapsulating the property and method of the Circle “thing” we just made, we’re not going to get any unexpected behavior.

Let’s say that I want a circle now, all if have to do is to declare an instance of the Circle class. So instead of writing those 6 lines, I’d just write:

var myCircle=new Circle();

That’s it. Presto-chango!, a circle appears on the screen! Now, just like you think of trace() and Shape as “things” in ActionScript 3.0, you can think of Circle as another “thing” you have at your disposal when programming. Likewise, just like Sprite and Shape, Circle has properties and methods.

For You OOP ActionScript 3.0 Beginners who are also Artists…

A while ago, we had some posts for artists who decided to do some coding with ActionScript 3.0. We made a series of three videos on some of the basics of OOP that all OOP beginners might find helpful.

Also, lest you think that we devalue artists on this blog look at our praise of artists (and animators).

Where's the Beef?

Particularly galling was Kevin’s pontification exhorting “academics” to get cracking with parallel programming (citing Paul Steinberg) :

If academia treats parallel programming and data structures like a specialized field of study, walled off into a couple courses and ignored by the general curricula, it will be doing a disservice to its students.

First of all universities do teach parallel programming. A new colleague of mine who just received his computer science Ph.D. from Georgia Tech (a southern version of MIT or India’s IIT) knew all about parallel programming; so, it is something that already is taught in “academia.” (That’s where the concepts were invented.)

Second, if we heeded Kevin’s advice, we’d drop the fledgling ActionScript 3.0 courses you can find here and there in universities and go C# big time. That’s because C# (along with Visual Studio 2010) support parallel programming and other than “my own team’s Pixel Bender in Flash” that Kevin mentions, there’s very little support for parallel programming from Adobe—at least support that’s visible and usable like it is with C# and the .NET framework.

Third, while there’s a brisk discussion at OOPSLA (SPLASH) meetings of parallel programming, there’s no one from Adobe there. (I’ve given several presentations using ActionScript 3.0 in design patterns at these meetings but have never met anyone from Adobe—lots from Microsoft though.) So, while MAX is dandy for the Adobe fanboys, and Intel Developers Forums are great for rallying Intel multicore solutions for hardware, the software giants are at OOPSLA where design patterns were invented. You’ll find (like me) that if you’re the dumbest person at a conference, you can learn a lot.

Let me apologize for this mid-week rant, but like a lot of us who are huge supporters of ActionScript 3.0, it’s very frustrating to see languages like C# and Java (and even Python) support parallel programming and then read a post like Kevin’s telling us to “hop to it” while not having the developer tools to do so. Even worse, if we took Kevin’s advice seriously, we’d probably use C# and C++ on the .NET framework and kiss ActionScript 3.0 goodbye.

Is only one of your processors doing all the work?

What Do the Multicores Do?

I have a few computers, and the ones that I use the most have multi-core Intel Core 2 Duo CPUs (Two Macs and a Win 7 PC.) The Intel Core 2 Duo processor has 2 processors (or cores), but from what I’ve read, one seems to do the work and the other one is mostly unused. If your processor is “quad,” you’ve got 4 processors; but you’re only using one—or more accurately, you might say that you have access to only one for programming. Perhaps the “other” processor may be doing some UI housekeeping or some other chore while the “processing” processor is working on your program, but it could be doing nothing. This would depend on your operating system. However, all I know for certain is that while programming, I can only program to a single processor at a time.

If we have a multi-core processors; why do write single-core programs?

Along with multicore processors is multithreading in programming. In a nutshell, multithreading is running two or more threads at the same time. A thread is a task your computer is processing and multiple threads are tasks that are part of a single process. Imagine several people working on a house at the same time. Some are working on carpentry, some on plumbing and some on masonry. Think of each task as a thread that are part of the same process—building a house. Most of the multithreading that goes on is handled by a single processor that quickly switches between tasks so that it appears that it is processing them simultaneously. If you’ve ever had to wait for a big fat graphic to be rendered, you have an idea of how handy it would be to have more than a single processor working on the graphic at the same time using multiple and parallel threads. Figure 1 illustrates this point:

Figure 1: Parallel processing two threads simultaneously.

Instead of static two-dimentional graphics, imagine three-dimentional animated graphics, and you can get a better idea of why multithreaded programming to multicore processors is important for applications like Flash and Flash Builder.

Before going on, some key concepts need to be quickly clarified:

• Multi-core processor: Two or more processors called “cores” reside in a single component. The cores can execute and read instructions (programs.)
• Multithreaded programming: More than a single thread can be programmed and processed simultaneously. In relation to a multi-core processors, separate cores can be used to process separate threads (tasks in a program.)
• Parallel Programming: Processing multiple threads simultaneously on different hardware resources or processing resources.
• Concurrent Programming: Programming instructions as collections of interacting computational processes. Often used in conjunction with parallel programming when multiple processing resources are available.
• Green Threading: The term “green threads” refers to the process of scheduling threads on virtual machines instead of the underlying operating system. Green threading is simply the process of creating green threads and the virtual machines to process them. (Green threadin’ refers to the same process while listening to boogie music.)

You can get a running start by looking at the first chapter of Multi-Core Programming: Increasing Performance through Software Multithreading by Shameem Akhter and Jason Roberts. ( The entire book is available for about $60.) Another good resource is a talk by GoF co-author Ralph Johnson where you can see the relationship between design patterns and parallel programs. Several ActionScript 3.0 Multi-thread discussions may be helpful. Jesse Warden’s has lots of information about green threading and some design patterns he tried. Speaking of green threads, you can find ActionScript 3.0 examples here at Generalrelativity.
(Continue to see an example using a little Factory Method.) Read more…