By paddloPayday loans

Home > Multi-threaded Coding > ActionScript 3.0 and Multithreading #1: Defining the Problem

ActionScript 3.0 and Multithreading #1: Defining the Problem

Is only one of your processors doing all the work?

Is only one of your processors doing all the work?

Beginners Welcome: In case you were looking for the next installment of our new OOP/Design Patterns series for Beginners, this post may throw you. It’s not for OOP/DP beginners, but since it’s an introduction to multithreading, concurrent and parallel programming, it should be pretty clear. The materials are presented at a definitional level with a simple Factory Method pattern to illustrate a point. Fear not, though. Next week, we’ll return with Part II of the beginners OOP/DP series.

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:

<em><strong>Figure 1:</strong>Parallel processing two threads simultaneously</em>

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.)

A Quick and Dirty Example

One way to get a sense of what’s going on in our multicore processors is to have a shot at a multithreaded program. This first one I set up is a Factory Method that has two loop products representing expensive processes (ones that eat up processor resources.) Figure 2 shows a file-class diagram:

<em><strong>Figure 2: </strong>Factory with Loop 'Products'</em>

Figure 2: Factory with Loop 'Products'

The Client simultaneously makes a request through the Factory for both a left and right loop concrete Product instance. Using the trace() statement, the left and right loop objects show up in Output (Flash) or Console (Flash Builder—be sure to run in the Debug mode in FB). Just for good measure, it uses a timer to make sure everything blasts off at the same time and runs it twice to see what happens in a second run. (Click the button to download the source code for the entire design pattern—both Flash Builder and Flash Pro.)
kilroy

?View Code ACTIONSCRIPT
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
package
{
	import flash.display.Sprite;
	import flash.utils.Timer;
	import flash.events.TimerEvent;
 
	public class Client extends Sprite
	{
		private var leftThread:Factory=new MakeLeft();
		private var rightThread:Factory=new MakeRight();
		private var threadTimer:Timer;
 
		public function Client()
		{
			threadTimer=new Timer(20,2);
			threadTimer.addEventListener("timer", multiThreads);
			threadTimer.start();
		}
 
		private function multiThreads(e:TimerEvent):void
		{
			leftThread.factoryMethod();
			rightThread.factoryMethod();
		}
	}
}

The Client class represents a starting point where two different threads are launched simultaneously—each to work on a separate concrete Product. It also shows the essential dilemma in running multiple threads on a single processor. No matter what we do, either the statement to start the left or right loop has to come first. We cannot achieve simultaneous launch because of the required statement sequencing—even inside a method. When you look at the output; here is what you see:
….
left :994
left :995
left :996
left :997
left :998
left :999
right :0
right :1
right :2
right :3
right :4
right :5
right :6
….

Instead of having interspersed left and right output, the objects are handled one at a time indicating that the two concrete products (loop output) are not threaded. As soon as the left loop finished the first time, it did not repeat itself until the right loop was completed. The timer (20 whole milliseconds) was enough to give the right loop time to jump in and execute its loop before the second set of loops were called. Were it true multi-processing, we’d see something like this:
….
left :994
right :994
left :995
right :995
left :996
right :996
left :997
right :997
left :998
right :998
…….

The problem with using a single processor is that we only can get multiple threads that have to take turns with the actual (single) processor. We have to think about making a virtual machine that will act like it has access to multiple processors.

Why Should I Care?

It took me a while to realize that Flash Builder and ASP.NET/C# in Visual Studio were very similar. Basically, Flex is to ActionScript 3.0 as ASP.NET is to C#. So what? Well, if you pay a visit to Amazon.com, you’ll find a load of books on Microsoft.NET parallel programming, including Parallel Programming with Microsoft .NET: Design Patterns for Decomposition and Coordination on Multicore Architectures (Patterns & Practices) co-authored by GoF co-author, Ralph Johnson. There’s a growing number of books about C# parallel programming with examples. This is not so much about playing follow-the-leader as it is about moving out of a comfort zone and into the stream of where microprocessing and programming architecture are headed. If you do a search at Amazon using “Parallel Programming” as the key, you’ll find lots of books about parallel programming, multi-threaded programming, multi-core processors, but none related to ActionScript 3.0.

The physics of the whole thing is pretty simple. It seems that processor speed has hit a heat wall. The current solution to processor over-heating is multiple processors. As Ralph Johnson put it the free ride is over, meaning that we cannot simply wait until the next, faster processor comes out to speed up our programs. To speed things up, we’re going to have to have access to multiple processors through language structures hooked into the OS and then develop algorithms and architectures to optimize their use in programming.

Paul Steinberg at Intel wrote and article entitled A Sea Change in Computer Science Education, and in it he made the following observations about preparing programmers for the future:

  • We should get beyond thinking about teaching “parallel programming” — it’s all just programming.
  • Parallelism must be introduced early into the curriculum – no later than second year, and it must inform all relevant courses.
  • New focus must be paid to architecture – but not the same architecture we’ve been teaching for years.
  • Design patterns will take on increasing importance.
  • Parallel models are no longer in their infancy – some are mature and can be widely adopted.

Steinberg’s words do not fall on deaf ears. As noted at last year’s OOPSLA (SPLASH) conference, the hottest topic was concurrent programming. In the early morning (4 am) chat I had with Ralph Johnson at last year’s SPLASH, all he talked about was parallel programming (in part, no doubt, because his book on the topic had just been published in September.) Multi-threading, concurrent programming and everything related to multi-core processors sitting in our computers, is not the latest fad; it is a path paved by the physics of microcircuitry. To me it’s a new challenge. Even better, it involves design patterns.

Conclusion

I can’t stand those pundits who go about making a fuss about every new advance that comes along in technology. First, many of them don’t know what they’re talking about, and second, what’s going to succeed or fail is a crap shoot. I certainly don’t claim to be an expert on programming in parallel to a multicore processor.( I’m an explorer in the area.) Further, there’s no assurance that it will be the NEXT BIG THING. (Maybe someone will come out with a nanoprocessor that works with quarks and atoms.)

What’s attracted me to concurrent, multithreaded, parallel programming is the difficulty in getting it off the ground. You have to change algorithms, re-think design patterns and work up virtual machines to get it working with ActionScript 3.0. In short, it acts like a gym for my brain.

As always, we’re very interested in your feedback on new topics. This one is certainly new, and as you have seen, we have not abandoned Design Patterns—if anything, their use will be even more important with multithreaded programs. So, let us know what you think and your ideas on this topic.

Share
Categories: Multi-threaded Coding
  1. April 3, 2011 at 3:22 pm | #1

    Totally agree with your view point here. Threading in actionscript is really a very important step that the language needs to take in order to stay relevant. Especially as we see the language moving into more application development than the traditional web animations.

    I can’t see an application language without threading surviving long, no matter how large the support for it is.

  2. April 3, 2011 at 5:56 pm | #2

    Hi Michael,

    It’s funny that several people have been looking at ActionScript 3.0 and parallel programming for a few years. (You can see some links in the post.) It’s ironic that we have to set up concurrent threads using a single processor while most of our systems are multi-core. In Flash Media Server there’s probably a good deal of multithreaded applications that actually spit the processing duties between the client and server-side and two different versions of ActionScript! Maybe that’s something else we can consider looking at as well to get some ideas.

    Kindest regards,
    Bill

  3. Andrea
    April 3, 2011 at 8:42 pm | #3

    Really interesting topic.

    I studied concurrent programming in Java at university, and I think, as well as Michael, it’s a fundamental feature for a language. I’m wondering what is Adobe’s position about it.

    Thanks for the article, hope you’ll keep writing about this topic.

    • April 4, 2011 at 1:37 pm | #4

      Hi Andrea,

      I’m not sure what Adobe’s position is. I’ve seen a few posts from some Adobe engineers, but I have not seen a “Let’s saddle up and do this!” statement. It’s hard for me to imagine that at least some of the engineers are not wondering about a move in this direction.

      Perhaps they’re waiting to see the reaction from the .NET people.

      Kindest regards,
      Bill

  4. April 4, 2011 at 1:21 am | #5

    Would it be really wise to start thinking about parallel programming when Adobe still hasn’t spoken about implementing multi thread support (and I mean, more than the event thread vs the main thread) in AVM?
    But I agree with Michael, I can’t see Flash surviving without multithread capabilities. Or without opensourcing the player.

    • April 4, 2011 at 1:52 pm | #6

      Hi Nicolas,

      I believe if we (Adobe’s customers and advocates) start moving the ball in that direction, we’re more likely to make parallel programming in ActionScript 3.0 (…or maybe 4.0) a reality. I know that I’m going to be playing around with C# parallel examples and the .NET framework to see what I might be able to bring over to ActionScript 3.0, and if I (and others) don’t see any movement by ActionScript 3.0 we might not come back. It’s Darwinian in the sense that who’s going to survive while clinging to a left-behind software technology? Languages like Python were developed as teaching languages for CS, and it has some kind of multi-threaded/parallel capability. It’s part of a much larger movement in software development that is attempting to catch up with and take advantage of multiple processors in our computers.

      So I think it would be wise to start seriously thinking about and learning about multithreaded programs. If Adobe is thinking along these same lines, I’d like to hear from them.

      Kindest regards,
      Bill

  5. Mike
    April 4, 2011 at 8:24 am | #7

    Two things I am wondering about:
    First is the flash pro settings for hardware accelleration 1- direct, 2- gpu which embedds the swf to the html with the WMode-tag set to “direct” (multicore support) or “gpu” which only takes effect when running the html but not directly out of flash… maybe this could be a further test to see if this is changing anything to the code above? (I doubt it)

    Second, if it’s actually possible to run a browser plugin with multithreads!?
    Java has the java.lang.Thread class since 2006 and runs in the same plugin-container as the flashplayer does (firefox).
    Unfortunately I couldn’t find an online java multithread demo or example in the net which runs in the browser..

    • April 4, 2011 at 2:06 pm | #8

      Hi Mike,

      One thing that Ralph Johnson must have said 10 times in his talk about parallel programming (in the .NET context) is that it’s hard. Your points are excellent ones, and ones that must be addressed—along with a host of others. Quite frankly, I really do not have answers for them.

      I became interested in parallel programming because Ralph Johnson talked my ear off about them at the last OOPSLA meetings. Then when I found that design patterns are an important part of the movement towards multithreaded and concurrent operations, it was more attractive. As I noted in the post, I’m an “explorer” in this area, and I’ll continue to be both because of the interesting aspects of the topic and the challenges in its implementation.

      You certainly nailed what some of those challenges are.

      Kindest regards,
      Bill

  6. April 4, 2011 at 10:19 am | #9

    This URL is interesting also on the subject :
    http://www.senocular.com/flash/tutorials/asyncoperations/

  7. Sharat Achary
    April 4, 2011 at 1:39 pm | #11

    Hello William,

    Very informative post. This took me right away to those parallel processing and multithreading sessions over Linux, during college. Though AS3 has much similarities with Java, it was hard to find something like multithreading in AS3.

    Let say we are loading ten large images simultaneously and showing their progress in AS3, what I initially thought was hey AS3 supports multithreading, but after reading quite some articles it was understood that those threads were processed sequentially either by round-robin or fifo, shortest job … algos ! Every thread had its short burst over the processor, shared resources, and other things to count upon.

    It took a while to get along, from Java to AS3, no pointers to fully reference supportive environment, though having similarities with Java yet no multithreading in AS3 (explicitly creating threads).

    I am going to keep my drawing board ready for the Posts that are yet to come in this series. It would be really a learning – “Design Pattern + AS3 + Multithreading”

    Humble regards,
    Sharat

    • April 4, 2011 at 2:19 pm | #12

      Hi Sharat!

      Very nice comment, thank you. Your example is a perfect one of why true multithreading and parallel processing is important for the Flash environment. (Then change it all to animated 3-D and you’ve got one busy processor!)

      Some years back, a bunch of us who were doing some work with Adobe threw a fit about getting regular expressions for ActionScript. The next release, ActionScript had regular expressions. Being an unrepentant optimist, I like to think that good things will come for good reasons. In this case, the good things are encapsulated in animated 3-D graphics and the good reason lies in multi-core processors.

      Kindest regards,
      Bill

  8. April 4, 2011 at 2:27 pm | #13

    A few people have incorrectly stated that Adobe has said nothing about multi-threading or concurrency. That’s not actually true. There have not been official announcements yet, but people on the Flash Player team have talked about active work related to this subject:

    Thibault Imbert: “Just to let you know, we are discussing this and working actively on it… today we are looking at an incremental approach with a first implementation similar to the BackgroundWorker API in C# or WebWorkers in JavaScript”

    Source: http://bugs.adobe.com/jira/browse/ASL-23

    I’ve seen similar info from several Adobe sources on Twitter and elsewhere. It’s not as exciting and demo-friendly as Molehill, of course, so that’s probably why William hasn’t gotten the “let’s saddle up and do this!” declaration he wants so much.

    • April 4, 2011 at 3:26 pm | #14

      Hi Josh,

      No drama here. It’s Bill; not William. Thanks for the information. I don’t think Adobe was incorrectly characterized by any of the comments here. Parallel programming is just not something that seems a priority at Adobe in relationship to what they’re doing elsewhere. While I’ve seen a few comments about using the capabilities of multicore processors (and certainly an interest among our blog’s readers), I don’t see the publications that can be found for .NET and C# (not to mention other languages). I’m sure that Adobe engineers are aware of the issues involved, but to characterize the comments here as “…not actually true…” because of some tweets and blog comments to the effect that something significant is going on with multicore usages does not negate any of the comments.

      Perhaps if you’re privy to information we’re not, you’ll share with us. I had seen your link before, and while that discussion is encouraging, it does not sound like a more than just that—a discussion that began in 2008…and is still a discussion.

      You’re right, the info from “several” Adobe sources you cite is not too exciting. I’m hoping it will become more so, and please let us know when it does.

      Kindest regards,
      Bill

      • April 5, 2011 at 10:04 am | #15

        Sorry, Bill. Your name shows up as William in big blue letters at the top of every comment. :)

        Though that particular discussion may have started in 2008, Thibault started commenting on it in late 2010. I’ve seen other mentions of web workers from him in recent tweets too. I don’t have insider info, but I’ve noticed that concurrency talk from Adobe sources has been on the rise. It’s beyond the old questions of, “how would you like it to work?” and hinting, to me at least, that they’re committing. It’s speculation, of course, but I’m finding it easier to read between the lines with Adobe over time.

        • April 5, 2011 at 10:27 am | #16

          Hi Josh,

          Thanks for that. The engineers at Adobe are a sharp set, and I guess it just irks me to see .NET so far out there ahead of ActionScript 3.0.

          I wish more of the AS3 people would come to conferences like OOPSLA (SPLASH) where I’d get a chance to meet them, and they’d get a chance to meet a lot of the leadership in software design and architecture. Parallel programming is all over the place and all the exciting new things are happening in concurrency. I’ve got nothing against MAX, but it’s a bit insular, and I think that the Adobe software engineers would enjoy it immensely!

          Kindest regards,
          Bill

    • April 5, 2011 at 9:20 am | #17

      At Adobe MAX 2010, during the Flex Roadmap session, Adobe talks about adding some sort of multithreading API, which I blog about here:
      http://matthewfabb.com/blog/2010/11/11/multithreading-is-finally-coming-to-flash/

      I speculate that these advancements might come with the next version of the Flex SDK. However, with AIR 2.6 now out and Flex 4.5 likely being released shortly that is clearly not the case.

      Still, Thibault Imbert keeps mentioning in blog post comments and on Twitter that some sort of multithreading API is in the works. Thibault has also mentioned that on Twitter that he has a very long blog post draft on the topic. He says he is still working on it but I also wonder if it’s something about timing and how far out it is from being finished.

      In the meantime, he has posted about asynchronous bitmap decoding in Flash, to help stop the locking of the UI, one of the major arguments on why a multithreading API is needed:
      http://www.bytearray.org/?p=2931

      Finally some more links on the subject:

      Green Threads by Drew Cummins
      http://blog.generalrelativity.org/actionscript-30/green-threads/

      Parsing & Rendering Lots of Data in Flash Player by Jesse Warden
      http://jessewarden.com/2009/02/parsing-rendering-lots-of-data-in-flash-player.html

      ActionScript Thread Library 1.0 from the Japan LibsSpark library:
      http://www.libspark.org/wiki/Thread/en

      • April 5, 2011 at 12:22 pm | #18

        Hi Matt,

        Thanks for the information and links! In the post I had included Drew’s and Jesse’s, but the piece you did was fabulous and those other links great as well.

        Speaking of links, Jesse Freeman, (AKA ‘Flash Bum’) provided some more very nice links about ActionScript 3.0 Green Threads. See http://bit.ly/dFCKCK and http://bit.ly/g170n2 . I am very happy to see that once the ActionScript 3.0 Multithread tree was shaken; lots of good stuff has come out. Thanks again!

        Kindest regards,
        Bill

        • April 6, 2011 at 11:27 am | #19

          Hi Bill,

          Opps! Sorry. I was on my lunch break and have to admit that I only skimmed the article because of limited time.

          Here’s 2 more links of experiments Ryan Taylor did in using PixelBender to do big number crunching, since PixelBender works on a separate thread:
          http://www.boostworthy.com/blog/?p=243
          http://www.boostworthy.com/blog/?p=268

          Unfortunately, it only works for certain use cases. I also vaguely remember at least one other developer blogging about similar experiments with PixelBender around the same time in late 2008, but I can’t find any of the links right now.

          • April 6, 2011 at 2:07 pm | #20

            Hey Matt,

            Thanks for those new links. I believe that Jesse Warden may have been the guy who mentioned PixelBender and multiple threads…and it too is on my to-do list.

            Jesse and I also did a lot of work with Flash Media Server and we may have done parallel programming and really didn’t think of it as such. In this series, I hope to consider parallel programming using FMS where one “processor” is on the client and the other is on the “server” — sort of a guerrilla parallel programming until we get the real thing.

            I ordered Parallel Programming with Microsoft .NET: Design Patterns for Decomposition and Coordination on Multicore Architectures (Patterns & Practices) and I hope to cull some wisdom that we can use is AS3.

            Take care,
            Bill

  9. April 4, 2011 at 9:39 pm | #21

    Great article. Thank you for the information.

    I am trying to think in terms of a game engine. Specifically in the render pass how I might utilize this by deferring some calculations to the next frame (so long as it is not perceivable) such that things are rendering every other frame.

    Of course with Molehill, we can offload some the CPU intensive drawing of the past. But still food for thought.

    • April 5, 2011 at 1:45 am | #22

      Hello as3isolib,

      I’d be very interested in learning more about Molehill and what your own project is all about in relationship to multithreaded programs.

      Maybe it’s just me, but I really was not thinking in terms of a frame-based solution even though I can see the possibilities. I’d be very interested in it as well and what’s going on with it as far as interleaving threaded code is concerned.

      Thanks,
      Bill

      • April 5, 2011 at 8:10 am | #23

        Hi Bill.

        Well as for Molehill, if you don’t know it’s just a set of APIs to delegate rendering to the GPU. I haven’t learned enough about it to really say much more but you can definitely dive in here – http://j.mp/f7F4Xc

        My project is a 2D isometric library/render engine. I have it running super fast now, but I am addicted and want more. I see some sort of ‘frame switching’ idea but haven’t given it much thought. I am thinking maybe ‘straddling’ two frames, one to perform the calculative logic and the other to perform the render logic. If you’d like to discuss maybe working on a proof-of-concept, let me know. i might be trying this out later this week now that the idea has spawned.

  10. April 5, 2011 at 7:38 am | #24

    Hi Bill,
    I thought about it a bit further, and somehow I remembered that SWiFs can communicate through flash.net.LocalConnection;

    Would your example work the right way, if we embed three swfs to one html page, the first is the actual mainView the other two are workers (LeftLoop/RightLoop) with a 1x1px stage size (not visible to the viewer) connected through LocalConnection bidrectional (send and receive) to the mainView?

    (as mentioned earlier the SWiFs should be embedded w\ wmode direct or gpu)

    Thanks,
    Mike

    • April 5, 2011 at 10:07 am | #25

      I once tried using LocalConnection and ExternalInterface to offload work between SWFs, or even to JavaScript. It always ended up causing the UI to hang on me. That was maybe a year or two ago, though, and newer browsers and Flash Player versions may be more capable.

      • April 5, 2011 at 10:13 am | #26

        Josh,

        Have you tried it with the newer player versions? I’d really like to see some examples of what you and Mike have tried.

        Thanks,
        Bill

    • April 5, 2011 at 10:12 am | #27

      Hi Mike,

      Do you have an example of what you’ve did?

      Thanks,
      Bill

      • April 6, 2011 at 3:28 am | #28

        Hi Bill,

        I just made a quick & dirty mock-up for that idea
        it’s rather the copy & paste code version than a impressive pattern one.

        there is a start_me_direct.html and a start_me_gpu.html (WMode direct vs gpu)
        and there is a known sync. problem with the workers wich requires the user to reload the page
        in order that both workers are running – you should see
        [0.51] go work, workers!
        in the worker#0 and #1 screen

        short description:
        master opens 4 channels – sending #mainChannel0/1 – receiving #workerChannel0/1
        worker0 and worker1 opens 2 channels each: receiving #mainChannel0/1 sending to #workerChannel0/1
        (it isn’t possible for both workers to connect to the same channel simultaniously…
        and it isn’t possible to run start_me_gpu and start_me_direct in the browser in two tabs simultaniously..)

        master/worker0+1 try to connect to these channels through localconnection with a 100ms sleep between attempts to avoid script-timeout (flashplayer freeze)
        when this “handshake” is successsful master sends “go work, workers!” to #workerChannel0/1
        workers0/1 send the for-loop results back to the master…

        download:
        http://bit.ly/hwkXei

        -mike

        • April 6, 2011 at 3:44 am | #29

          Hi Mike,

          Thanks for that. After work, I’m going to give it a run. Your ideas and comments (not to mention your code!) have contributed a great deal to this discussion.

          Kindest regards,
          Bill

  11. Matthew Zimmer
    April 7, 2011 at 9:54 pm | #30

    Bill, I am so glad you wrote this article! As you said in an earlier comment, “I am very happy to see that once the ActionScript 3.0 Multithread tree was shaken; lots of good stuff has come out.” You took the words right out of my mouth! :-)

    As soon as I learned last year, February 2010, that Thibault was hired by Adobe to join the Flash Player team, I knew then that ActionScript developers were in for a treat. I just didn’t expect things to change this quickly (Flash on a mobile device, what? Eat your heart out, Steve Jobs. ;-)

    I <3 the AS community! You guys rock!

    • April 8, 2011 at 1:07 am | #31

      Hi Matt,

      It’s funny, parallel programming seemed to go from 0 to 100 even though when you do a little snooping, it’s been on developers’ minds ever since multicore processors became available. It just seemed that last year, the OOPSLA Educators Symposium was worrying about when to introduce OOP and Design Patterns and this year the topic is Post-OO Computer Science Education.

      As Ralph Johnson pointed out, “There’s no free ride anymore” as far as waiting around for single core processing to get any faster. We either start experimenting with multithreading or bang our head against a hardware wall. The more I think about it, the more I’ve come to realize that this change (multicore processors->parallel programming) is the biggest change in programming since…well, ever. Certainly since OOP and Design Patterns. However, rather than sitting around 10 years (a decade!) or so like I did with DPs wondering whether parallel programming is a good idea or not, I’m trying to get going even before all of the tools are in place. What could be more fun than tinkering with multithreading and finding ways to write pseudo-parallel programs until we can grab every core in our processors?

      Kindest regards,
      Bill

  12. Mark A.
    April 8, 2011 at 9:39 am | #32

    I would Love to see parallel Programming in as3 or any Otter modern Language to Be more abstract. I do Not think its a good idea to bring multithreaded coding to the Flash Platform without further abstraction meaning that you do Not Need to deal with all the hurdles like Dead locks or other Problems with concurrent access to Resources. I do Not have an idea how but thats Not my Job anyways :-). It would Be fantastic to simply put Parts of your Programm in a different thread (the mentioned Game Engine, ai calculations, Path Finding etc) but without the Need to worry. THAT would Be the Next Big step After patterns – Not just to mimic the old Way. (Text was written on ipad2 with German Language selected. The damn Auto Spelling correction And word Suggestion Drives me Crazy.)

    • April 8, 2011 at 11:21 am | #33

      Ach du Lieber Himmel Mark!

      Your iPad2 with German is no dummkopf–I can barely speak one language…

      Anyway, I think you’re trying to say, you’d like to see some higher level language constructs to handle multithreaded coding instructions–maybe like those Otter (or is it Otto?) languages. One other language that has some nice ones is C#. For instance, if you want to add a second thread, you’d enter something like:

      using System;
      using System.Threading ;
      
      class DoThread
      {
          static void Main()
      {
         Thread threadTwo = new Thread(loopTwo);
         threadTwo.Start();
         for(int count2=0; count2 < 500; count2++)
         {
           Console.Write("T1");
         }
      }
      
          static void loopTwo()
          {
              for (int count1 = 0; count1 < 500; count1++)
              {
                  Console.Write("T2");
              }
          }
      }
      

      The only term I had to add was a Thread instance.

      Mit freundlichen Grüßen,
      Bill

  13. Mark A.
    April 10, 2011 at 9:25 am | #34

    Sure, something like that. And does this construct handle parallel access to resources on its own? I mean if two threads share some data (ready,write) is it easily handled by the language? I remember disapointing things like semaphors to prevent dead locks and such in c++ (was it just C?) Although I’m aware that there is no automated solution for any case I would love to see some simplifictations…

    • April 10, 2011 at 6:04 pm | #35

      Hi Mark,

      I haven’t spent enough time with C# parallel programming to tell you. I’m (slowly) working my way through Parallel Programming with Microsoft.NET by Campbell, Johnson, Miller and Toub. It’s a very nice book, but it introduces so many new concept and general design patterns for parallel programming, it’s not as fast of a read as it looks. I hope to cull some ideas and try and use them with some green threading with ActionScript 3.0. Also, I’m going to have to spend some time with Pixel Bender (PB) to see if I can get more general applications in Parallel programming. I took a quick glance at http://www.flashmagazine.com/tutorials/detail/using_pixel_bender_to_calculate_information/ but I’m afraid that PB may be a bit too specialized for general parallel apps.

      Kindest regards,
      Bill

  1. No trackbacks yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>