A sneak peek: Concurrency with ActionScript Workers

This week we just shipped Flash Player 11.3/AIR 3.3 with lots of cool features for mobile and desktop. But, we are already finalizing the last details on a brand new feature coming very soon, ActionScript Workers. Planned for the next Flash Player/AIR release, I am super excited about this feature. Here's why.

The concept of concurrency is kind of the holy grail for most ActionScript developers who are working on complex projects. How many times, have you had issues with the UI locking and having to distribute computations to frames like crazy? How many times did you have to optimize your algorithms like crazy to minimize the cost of execution and reduce the risk of UI locking? Yeah, you have been there.

Concurrency has always been popular in the Jira(290 votes), I remember having conversations over there with many developers following the status of this feature, I am sure some of you may think, well, better late than never. Again, the focus we have now on gaming or video, allows us to focus, so deliver valuable features like those much quicker.

See all the features we introduced between Flash Player 11 and 11.3, most of the biggest requests from ActionScript developers are getting delivered and we will not stop there :)

We started working on this feature last year, at that time, we were debating over how we would introduce concurrency to ActionScript developers, through a simple and safe way. We decided to go with a workers approach, cause it is a design most developers are today familiar with, which also can be API based rather than language based. We knew that we would not introduce a new keyword (for now) to leverage concurrency, so really workers made a lot of sense.

How does it work?

I will cover the feature in much more details when we ill have our first public beta, but here are some details about it. Like you would expect, you can create workers through a Worker API. The Worker takes as an input a SWF in the form of a ByteArray, which will be generated by the compiler and injected to create your Worker. Flash Builder will support this nicely and transparently, any other IDE you use will also support this when they implement concurrency support.

Before we start, let's cover two simple notions. In this article, we will refer to the UI worker (the one you always worked with in the past) as the primordial worker. It is still the entry point of your app, the primordial worker is never created by user code and is created automatically by the runtime, it is essentially your good old document class, extending Sprite at least.

So to create your child worker from the primordial worker, you will just write:

var worker:Worker = WorkerDomain.current.createWorker(Workers.EncoderWorker);

As you can see, the Worker is created through the help of the WorkerDomain object, that you can see as a factory. One and only WorkerDomain object exists for the entire runtime, and cannot be constructed by user code. Workers.EncoderWorker points here to our embedded worker using the [Embed tag].

At this point, our background logic is not executed, to trigger this, we simply use the start() API:


Now, the code you would have in the constructor in your background worker is started and waiting for the action. The Worker class has a state instance property to allow you to check at any time which state is your worker in. The different states are available through constants of the WorkerState class: NEW, RUNNING, TERMINATED

You could create as many workers was you want, but keep in mind that it is costly to create tons of them, each Worker is in fact a constrained virtual Flash Player instance, so it has a cost in memory (5-7mb). Ok, so now we need to communicate between workers. For this, please welcome the MessageChannel API. To communicate and send a message from a worker to another, you would create such a message channel like this:

var mainToBack:MessageChannel = Worker.current.createMessageChannel(worker);

The Worker.current call refers to the current worker (the primordial) worker, communicating with the background worker, passed here in parameter of the createMessageChannel API.

Now, we have our messaging channel in place, at any time, we can just call send() on the MessageChannel object to pass data to the background worker. But wait, we need a way to retrieve this message channel on the other side, so that we can communicate. For this, you will use the setSharedProperty API, which will put a reference to your message channel so that the child worker can grab the reference and listen to the messages coming in.

So, from the primordial worker you would write:

worker.setSharedProperty("mainToBack", mainToBack);

And in your child worker:

mainToBack = Worker.current.getSharedProperty("mainToBack");

Note that the String used here should be (to make things clean) something reflect the package of your program, I am using here something obvious to reflect the direction of the communication very clearly. So there we are! To pass data, we can now use our message channel pipeline. Also, remember that the setSharedProperty API can also be used to simply pass values to be used during the initialization of the Worker.

In your application you may want to send data like a String, a Number, an Array or other lightweight types like this, for this you can just use myChannel.send(), the protocol used behind the scenes is AMF3. You can also send custom classes, it will behave as a ByteArray.writeObject/readObject. You would then need to register your class with registerClassAlias. For the ones familiar with Flash Remoting or Flash Media Server, you guys get the idea, your data will be copied and serialized through the rules of AMF3. So no way to pass any DisplayObject between workers for instance, as it is not supported by the AMF3 format. Also, keep in mind, that most data types passed through MessageChannel are serialized (copied) at the exception of a few I will cover later in this article.

So let's say you want to pass an int to a worker, you would write:


On the other side, you would simply write:

var value:uint = mainToBack.receive();

You would usually place the receive() call in the Event.CHANNEL_MESSAGE event handler dispatched by the MessageChannel object. Now, the receive() call has two flavors: Synchronous and asynchronous which is actually super useful. In some cases you may want to block and wait until the sending worker has sent the message, that's why there is a blockUntilReceived parameter on the receive() API. By default, it will not block.

You can also queue multiple messages:


On the other side, you can consume them by just checking the messageAvailable property on MessageChannel and consume each of them by keep calling receive().

while ( mainToBack.messageAvailable )

So now you may wonder, ok this is really cool but what if I have big amount of data to transfer, like, let's say a BitmapData, or more simply a ByteArray? Well, here comes shared memory to the rescue!

Shared memory

Using shared memory is the most efficient way to transfer data between the workers. Essentially, it is a simple ByteArray class, the one you know which now has a new magical property: ByteArray.shareable

To pass around a reference to your shared memory, you use the same MessageChannel.send() API, but when you pass a ByteArray, it is not serialized, just referenced. Once you have a shared bytearray, you can pass anything you want between the workers, nothing will be copied but shared. So let's say you want to pass the same primitives we sent earlier, you would just do:

sharedMemory.position = 0;

On the other side, you just retrieve that simply:

sharedMemory.position = 0;
var value:uint = sharedMemory.readUnsignedInt();

Of course, you can queue different things, like:

sharedMemory.position = 0;

The variable textures would refer here to a ByteArray containing your compressed textures, and voila. You could pass them that way, simple, right?

Working with pixels

Knowing that workers would be used for image processing also, we also added a new API to BitmapData called copyPixelsToByteArray to work nicely with the concept of shared memory. This allows you to pass efficiently the pixels of a BitmapData to the shared memory, without having to have a temporary buffer you would allocate and copy the data from. That way, you can just write:

myBitmapData.copyPixelsToByteArray(myBitmapData.rect, sharedMemory);

And done. The pixels are transferred and accessible on the other side to be displayed or processed for any kind of work. I am sure you guys will find this one super useful ;)

Race conditions

As expected, if you have a shared memory between n workers, and that workers try to read or write to the same memory at the same time, you are on for troubles. To prevent this, you need to use mutual exclusion locks. That's why we will be introducing a new  flash.concurrent package with new classes : Mutex and Condition.

I will provide more details on those two guys later on with some examples. I suspect most developers will not necessarily need those, given that most developers will either just use 2 workers or multiple shared memory objects. You will really need to work with mutexes in the case where you need the multiple workers to read and write in the same memory concurrently, which can happen for some specific use cases!

What is accessible from a child Worker?

Not everything is accessible from a worker, obviously you cannot display things from a child worker and things like access to the Mouse, Camera and other UI APIs are also not available, but pretty much all the rest is. A display list is available, so that you can nest things, render them offscreen and work with that, for instance to rasterize things to a BitmapData. All network APIs are also supported if you need to load things in the background, super useful.


I finished porting a cool Alchemy lib (ShineMP3Encoder) from Cyril Diagne (flash-kikko), to perform MP3 encoding at runtime from a .wav file.  Today the lib performs in a single threaded mode affecting the UI thread. I ported it to leverage workers, each file encoding can now be parallelized using workers without ever impacting the UI thread. Here is a little video demonstrating the project:

I hope you guys are excited about it!

Comments (95)

  1. David Q Hogan wrote:

    Great news – we will definitely use this for processing large web service responses, etc. ! How will it behave on single core hardware such as an iPhone 4? Are worker threads set at a lower priority?

    Monday, June 11, 2012 at 5:45 am #
  2. Tony wrote:


    Monday, June 11, 2012 at 5:47 am #
  3. Adi Nugroho wrote:

    This is awesome :) I never worked with worker/thread before, but your explanation and as3 implementation is very easy to understand. I Love this ^_^ I Love flash player, I Love Adobe =)

    Monday, June 11, 2012 at 5:57 am #
  4. Thibault Imbert wrote:

    Hi David,

    For the first version of Workers, it will be desktop only for Flash Player and AIR. Mobile support will come in a future release!


    Monday, June 11, 2012 at 5:59 am #
  5. Conrad Winchester wrote:

    So, if I use the 3d libraries in conjunction with the shared memory for workers – do I have to pay a license fee?

    Monday, June 11, 2012 at 7:57 am #
  6. Conrad Winchester wrote:

    By 3D libraries, I mean the hardware accelerated molehill API’s

    Monday, June 11, 2012 at 7:58 am #
  7. Thibault Imbert wrote:

    Hi Conrad,

    No, you won’t have to. Workers are not a premium feature.


    Monday, June 11, 2012 at 8:04 am #
  8. Jerome wrote:

    Wow ! :)

    Monday, June 11, 2012 at 8:08 am #
  9. greg wrote:

    Great news.
    Little offtopic: will you plan to support ARMv6 processors?

    Monday, June 11, 2012 at 9:01 am #
  10. Henke37 wrote:

    Looks a bit heavy weight to me. I worry about code duplication.

    Monday, June 11, 2012 at 9:43 am #
  11. Great work !

    Just had a look at BitmapData updated docs, and i can’t find the copyPixelsToByteArray method ? Is it there finally in Flash11.3 ?

    Monday, June 11, 2012 at 9:43 am #
  12. Thibault Imbert wrote:

    Hi Eric,

    This API will be added in the same release as Workers, very likely to be the next release, not 11.3 which has already shipped.


    Monday, June 11, 2012 at 9:52 am #
  13. Thibault Imbert wrote:

    Hi Henke37,

    The API surface is quite small. What do you mean by code duplication?


    Monday, June 11, 2012 at 9:53 am #
  14. julio wrote:

    Bonjour Thibault!

    J’ai télécharger le playerglobal.swc (11.3) afin de tester les AS Workers mais je ne n’arrive pas à importer les packages.
    FlashBuilder ne trouve rien quand je commence à taper Wor…

    Monday, June 11, 2012 at 10:03 am #
  15. Rushme wrote:

    Great news.
    Is that Worker will only take a SWF file as input?

    Monday, June 11, 2012 at 10:28 am #
  16. Wow Cool… I need to understand little bit more.. Thanks for the great explanation…

    Monday, June 11, 2012 at 10:31 am #
  17. Hivaga wrote:

    Ok. I understand the data will be passed from main Thread to workers via


    and received in child worker

    var value:uint = mainToBack.receive();

    But there is no identifier for the data, because ok how could the worker identify what exacltly data have been passed to it?

    Do you have something like:


    Some way for the worker to identify the data passed to it. Or you expect us the data to be put in object and pass it like this:


    Overal i think this feature is great. Good job :)

    Monday, June 11, 2012 at 11:04 am #
  18. max wrote:

    Wow! Not ever think it’s possible in as3.

    Monday, June 11, 2012 at 12:07 pm #
  19. Danik wrote:

    Sounds like a great addition!

    I think this could help in a current project of mine where the user draws lines on a canvas.
    If the mouse input was on a separate worker from the drawing the lines would be much smoother I believe.

    Monday, June 11, 2012 at 1:14 pm #
  20. Gary Paluk wrote:

    Excellent stuff, can’t wait to start using threading in ActionScript. As you already know from our conversations Thibault ;D

    Monday, June 11, 2012 at 1:46 pm #
  21. Mahron wrote:

    Great stuff. Now we can move on and cry about the next thing : native mp3 and h264 encoding ;)

    Monday, June 11, 2012 at 2:18 pm #
  22. HB wrote:

    I don’t want to sound harsh or try to bash anyone, I’m a big supporter of Flash indeed, but I’ve got the feeling that something is missing, Adobe hasn’t invested as much as possible into this or something.

    First, having to use a separate SWF is somehow a drawback, being able to use internal functions or classes would be better, although I get that would make it harder to adapt to the current mechanism. Although maybe it could be done in a similar way to IEventDispatcher.

    Second, Adobe first announced that a shared model was not going to be implemented, although a lot of us requested support for it, and that nowadays there are methods to copy large chunks of memory in an efficient way. Now it seems the original proposed way is not implemented, isn’t it?

    Of course, I’m happy for having threading support, I just hope it’s up to everybody’s expectations, and that ~7mb memory usage is not a problem for mobile.

    Monday, June 11, 2012 at 3:21 pm #
  23. Thibault Imbert wrote:

    Hi HB,

    For your first question. The fact that a SWF is created behind the scenes is transparent with proper tooling support.

    For the second one. It is true, initially we did not want to expose shared memory. But yes, we changed our mind. Thinking about the possibilities of what people could do with it was very exciting and possible in the timeframe so we did it. This results in a feature which is more flexible and allows way more use cases.

    Also, we decided to do this because we know that most AS3 developers are now seasoned developers and know what they are doing, so we wanted to give them more power. The feature remains safe, people will just need to know what they are doing when it comes to shared memory! :)

    For mobile, Workers will not be introduced on mobile for ActionScript Workers 1.0 but in a future release. We have plans on how to make this work on mobile, but it was too short to make it happen. It gives also a way for developers to start using it on desktop very soon, get used to it and use it on mobile later on, with I am sure some feature requests :)


    Monday, June 11, 2012 at 5:36 pm #
  24. kun wrote:

    fully agree No#22 floor HB said:

    1. adobe not support multi-thread untill now is disappointed.
    2. the way adobe going supported, with a seperate SWF, is bad! it become very hard to pass non-primitive data.
    3. the cocurrnent of flash is new a flash runtime ,is bad!

    Monday, June 11, 2012 at 5:56 pm #
  25. gary wrote:

    i first thought that this was a fake or joke…this is so amazing, i waited for this feature since over years.

    thanks for sharing the info!!!!

    Monday, June 11, 2012 at 6:00 pm #
  26. kun wrote:

    with so many years, why adobe cannot also support multi-thread like “new Thread()”. The seperate SWF make object instance transfer hard to implement, the reflection again kill huge performance. And “new a flash runtime instance” to implement concurrency is truly ugly. I love FLASH/FLEX, but things make disappointed.

    Monday, June 11, 2012 at 6:07 pm #
  27. Thibault Imbert wrote:

    Hi Kun,

    1. adobe not support multi-thread untill now is disappointed.

    We know it took some time, but it is going to be available in the next release which is still a good news :)

    2. the way adobe going supported, with a seperate SWF, is bad! it become very hard to pass non-primitive data.

    This is not true, you can pass non-primitive datas, arrays, literal objects or a Vector. You can also share memory, which is something truly valuable.

    3. the cocurrnent of flash is new a flash runtime ,is bad!

    It is essentially another VM running in parallel. Doing a multithreaded VM would require more time and at the end of the day, this model works beautifully on desktop and gives you guys access to multithreading sooner.

    It is always a question of compromise and tradeoff ;)


    Monday, June 11, 2012 at 7:40 pm #
  28. Thibault Imbert wrote:

    Hi Kun,

    Also, new Thread() would not necessarily make things easier. I would be happy hearing about your limitations in the future using ActionScript Workers, that way we could see how we can improve them or decide if truly low-level threads would be required.


    Monday, June 11, 2012 at 7:58 pm #
  29. Henke37 wrote:

    To clarify my concern about code duplication, I am referring to when multiple workers need to use the same code. Especially complicated problems may want to have the same classes in both the main gui worker and the background worker.

    And that is ignoring the worry about being unable to share instances of classes without paying for serialization and deserialization. Possibly twice if you want results back.

    Reallife example of both concerns: I have an AIR application that reads in files from Nintendo DS games, loads the data up in useable structures, then uses the Flash display list system to draw it to a BitmapData that I encode as a PNG.

    At the same time I also offer to view and edit the files interactively in another part of the program.

    If I were to use workers then I would need both workers to have a copy of the code related to the custom file formats.

    As for the serialization issue, I would have to serialize some rather complex data structures if I were to give the background worker a copy of the current files that I have parsed in the GUI worker. Sure, I am not likely to need to do this in my case, but there are other scenarios, such as a more heavy editor with background exporting. Like Flash Pro if it was a Flash application.

    Monday, June 11, 2012 at 8:35 pm #
  30. Lucas Lorentz wrote:

    Hi Thibault,

    It’s very cool!

    I’m using ShineMP3Encoder on a project, and I intend to use Workers as soon as it get released.

    But I believe that if I publish SWFs targeting Flash Player 11.2 or above, alchemy 1 will not work, right?

    If I’m right, how did you make that demo? :-)

    New flash players will allow alchemy 1 again?

    Monday, June 11, 2012 at 9:15 pm #
  31. Thibault Imbert wrote:

    Hi Lucas,

    Remember, Alchemy 1 will actually work above 11.2. You would fall into the premium licensing ONLY if you were using Alchemy opcodes and Stage3D in the same project. In this case I am not using Stage3D, so I am good!


    Monday, June 11, 2012 at 9:27 pm #
  32. Victor wrote:

    I understand this was probably the most practical way for you guys to go about implementing some form of concurrency in a reasonable timeframe, but I can’t help but feel let down. Like others, I’d hoped for a Java-like implementation.

    Also, I suppose it just didn’t fit the roadmap to invest in re-engineering the AVM to support multithreading, with the whole HTML5 thing and all…

    Nonetheless, it’s better than nothing and keep up those short, feature-driven release cycles! :)

    Tuesday, June 12, 2012 at 1:15 am #
  33. Thibault Imbert wrote:

    Hi Victor,

    All correct. Except for the HTML5 part, which really does not impact our feature schedule. It is a parallel effort at Adobe.

    But you are right, it was about bringing it with a reasonable timeframe, valuable to all developers today using AS3.

    We will keep delivering with short release cycles! Happy you appreciate that.


    Tuesday, June 12, 2012 at 1:26 am #
  34. David Q Hogan wrote:

    Thinking further – being able to instantiate and initialise a complex display object tree in a separate thread would be beneficial for apps that use a lot of animated transitions and use the time bought by the animation to make web service calls, etc.

    Will there be any way to pass display objects from the worker to the main thread to be added to the stage? I’m guessing not at this stage.

    Tuesday, June 12, 2012 at 7:02 am #
  35. Thibault Imbert wrote:

    Hi David,

    Not at this stage. You have two ways to pass data. Shared memory through a ByteArray which does not support display object serialization. And using MessageChannel uses AMF3 which also does not support display objects. You can however draw your tree inside a BitmapData and pass the pixels around through shared memory and copyPixelsToByteArray.

    Hope this helps!


    Tuesday, June 12, 2012 at 7:59 am #
  36. gary wrote:

    Hi David,

    this is a good point. Without testing the new worker feature i´m also thinking if its possible to run an AES decryption class in the “worker background”. Currently, when i pass data from server to flash with some bytearrays, the complete video and UI stops (freeze) until the data came decrypted back so that i can pass them to the appendBytes method of the netstream object.

    i red that in flash player 11.x video decoding is multithreaded, but the whole video process stops when you process bytes in a for(;;…) method.

    That make me thinking about that with the new worker function i can process the decryption process in background. The 7 megabytes of an instance is not a big problem i think.

    I can’t wait to test this new feature.


    Tuesday, June 12, 2012 at 9:49 am #
  37. Elliot Geno wrote:

    This is awesome! No more Pseudo Threads!

    Tuesday, June 12, 2012 at 4:56 pm #
  38. Nikolay wrote:

    Will the main SWF’s AplicationDomain be a parent of Worker SWF’s ApplicationDomain? Or are the AplicationDomains of all Workers completely isolated?

    Tuesday, June 12, 2012 at 4:59 pm #
  39. Thibault Imbert wrote:

    Hi Nikolay,

    That is correct, they are isolated.


    Tuesday, June 12, 2012 at 6:01 pm #
  40. Vemilyus wrote:

    Hi Thibault,
    there is one point that was mentioned earlier but was kind of swept under the carpet: Why use the multiple SWF approach instead of a Java like solution for threads/workers?
    You wrote that with ASWorkers v1 mobile platforms are not supported. That implies that there will be future iterations that make mobile workers on possible.
    Now here comes the tricky part: How would you do this with e.g. the Apple iOS platform? Currently we are not allowed to load external code (other SWF files) at runtime. But if the workers work just like this, won’t there be problems at the core of the runtime?

    I recommend you just save yourselves the trouble by writing a feasible and reliable worker implementation like it exists with Java threads (IRunnable, etc…)

    Regards, Vemilyus

    P.S.: From what I have read about ASWorkers in this post, I am not overly convinced that this is an optimal solution. I will therefore stick to robust Pseudo Thread implementations which force the developer to write good code.
    In my opinion devs only use multithreading when they cannot find a proper and fast solution to a problem.

    Tuesday, June 12, 2012 at 6:32 pm #
  41. Chineis wrote:

    Hi Thibault.
    What happen if I develop an aplication and I use workers on my code but my user have an old single tread computer?
    Does it throw some error or it simply mantain all the processing on the main(and in this case the only) thread.
    Tks in advance.

    Tuesday, June 12, 2012 at 7:06 pm #
  42. Thibault Imbert wrote:

    Hi Vemilyus,

    Why use the multiple SWF approach instead of a Java like solution for threads/workers?

    Because it would have required to make the VM multithreaded which is not something we could do in the next releases, plus, we really did not want to expose the full complexity of threads. Workers offer a great safe and approachable solution for concurrency for the web. Even Microsoft is today pushing developers to use APIs like BackgroundWorker as much as possible rather than low level threads cause it just makes life easier. We developed this feature with the same mindset.

    Currently we are not allowed to load external code (other SWF files) at runtime. But if the workers work just like this, won’t there be problems at the core of the runtime?

    Yes, that’s why we will not support mobile in the first release. Concurrency 2.0 will very likely introduce a variation in the design which will work on mobile.

    In my opinion devs only use multithreading when they cannot find a proper and fast solution to a problem.

    I disagree with that. Why not leveraging multiple threads when possible? I agree that this can be badly used sometimes, hence why we went to the workers route. When used cleverly, it enables great things that would be extremely hard to perform in a single threaded environment.


    Tuesday, June 12, 2012 at 8:37 pm #
  43. Thibault Imbert wrote:

    Hi Chineis,

    Most desktop computers today are equipped with multicore CPUs. On a single processor, the workers would not run at the same time but one after the other. But context switching would be performed so quickly that you would not even notice, it would look like they would run in parallel.

    So you don’t have to worry about this :)


    Tuesday, June 12, 2012 at 9:11 pm #
  44. RJ wrote:

    I’m planning to move our Flex-BlazeDS server communication code to a background worker in hopes of eliminating the freeze associated with huge data coming in/out.

    However, based on the design of having a separate worker SWF file, does it mean that my separate worker SWF file will also need to register/link all the remote classes in addition to my main application SWF?

    Also, there would be minimal to negative improvement since I would have an additional serialization stage like so:

    Without Workers:

    server application SWF

    With Workers:

    server worker SWF application SWF

    Wednesday, June 13, 2012 at 4:03 am #
  45. Rodislav wrote:

    you know, flashplayer is almost here, with such awesome features, and it’s not available on linux as debug/standalone player… it makes me cry :-((

    Wednesday, June 13, 2012 at 8:39 am #
  46. Nikolay wrote:

    It seems as if the workers were pretty much useless for 2D or 3D engines based on stage3D. At first glance i can’t see how i could implement techniques like data parallel model or synchronous function parallel model. The only way to use workers i see is to move tasks like loading textures, acessing local storage etc. away from the primordial worker. But that wouldn’t increase overall performance of the engine.

    Wednesday, June 13, 2012 at 10:46 am #
  47. joa wrote:

    WOW! Multithreading! Omg, thank u A LOT! We’ve got a large flash app and the ui-freezing made us go into optimization for like a month, workers would be of a HUGE help ^_^

    Wednesday, June 13, 2012 at 1:57 pm #
  48. Is this shared memory bindable to domain memory? Can we use the fast memory opcodes with workers?

    Wednesday, June 13, 2012 at 9:13 pm #
  49. Thibault Imbert wrote:

    Hi Ryan,

    Yes, you could in the future :) And Yes, you can use the fast memory ops with Workers. Proof is, this demo uses the alchemy opcodes given that I am using here an Alchemy lib to encode to MP3 at runtime.


    Wednesday, June 13, 2012 at 9:19 pm #
  50. Erick wrote:

    Will this be available only for the web version of flash or just AIR?

    Thursday, June 14, 2012 at 6:54 pm #
  51. Thibault Imbert wrote:

    Hi Erick,

    Both Flash Player and AIR but desktop only in the first release.


    Thursday, June 14, 2012 at 8:09 pm #
  52. Christian wrote:

    I can see how this would be useful for Stage3D: rendering a lot of objects. First you have to recalculate every matrix on each frame (unless you cache them, which requires a lot of memory), unless you use batching, but that also takes a long time, so Workers could help either way. And if you call the Worker on each frame, passing in the context3D, it can do all the rendering for you. Plus it can do all the stage3d initialization, while you initialize the HUD, and load whatever saved data there is.

    Saturday, June 16, 2012 at 8:36 am #
  53. Daniel wrote:

    Does this take advantage of hardware threads?

    Saturday, June 16, 2012 at 6:40 pm #
  54. Jason wrote:

    Am I correct in saying that theoretically this feature could come to Air for Android mobile devices given that they can load in SWF’s at runtime?
    Also, how is the API likely to change from the initial implementation to the one that will allow all mobile devices to access Workers?

    Monday, June 18, 2012 at 11:50 am #
  55. Asad wrote:

    Wooohooo! I think concurrency would increase robustness and flexibility for ActionScript workers! Something to look forward to definitely! :D

    I think i will try and incorporate it on 02geek.com

    Monday, June 18, 2012 at 12:05 pm #
  56. americancuervo wrote:

    get sum !!!

    Wednesday, June 20, 2012 at 6:54 am #
  57. theguaz wrote:

    hey, nice feature u have there Thibault, do you think that in a near future we could use this to implement camera related bitmap processing on mobile? (AR, Face detection, pattern matching, etc).

    Also, the new “GEMS” u mentioned in earlier posts are gonna be released on that same version of AIR?


    Wednesday, June 20, 2012 at 11:52 pm #
  58. Cephas wrote:

    Hi Thibault,

    this is a big step. Great work!

    Will it be possible to use AS Workers for deserialization of objects coming from a Java backend (BlazeDS)? Currently the UI freezes during deserialization of complex objects.

    Thursday, June 21, 2012 at 3:38 pm #
  59. We are quite thrilled since a week, but are there any known release date ?

    Nothing was specified from Adobe.

    Thursday, June 21, 2012 at 5:32 pm #
  60. Thibault Imbert wrote:

    Hi theguaz,

    Yes, I actually have a working example using Camera for face tracking. I will post it also. And yes you acre correct, the “gems” I posted a little while ago will be released in 11.4/AIR3.4.

    Actually, there is one big thing in this release which will be great for this use case. You will now be able to directly get the pixels from the camera feed copied to a ByteArray or Vector without having to render the stream inside a Video object and draw it with BitmapData, all that is not required anymore. You juste use Camera.copyPixelsToByteArray or copyPixelsToVector.


    Thursday, June 21, 2012 at 7:26 pm #
  61. Thibault Imbert wrote:

    Hi Cephas,

    Yes, it will be possible. Background workers have all the Network APIs available and the ability to serialize/deserialize like you would do from the UI thread.


    Thursday, June 21, 2012 at 7:27 pm #
  62. Thibault Imbert wrote:

    Hi Nicolas,

    I cannot share the exact date for now cause we are almost done with the feature but dates could always slip. But we are working hard to have it out in the street very soon. Stay tuned, definitely.


    Thursday, June 21, 2012 at 7:34 pm #
  63. Damian wrote:

    I know you can’t share the exact date, but I’m currently working on a project and would find a huge use of that capability. Would the estimated release date exceed two months from now? Thanks.

    Friday, June 22, 2012 at 11:36 pm #
  64. DavidK wrote:

    Will the release coincide with the pre-release of alchemy2? I’d love to be able to re-create your demo at least ;)

    Monday, June 25, 2012 at 3:56 pm #
  65. DavidK wrote:

    I know it’s kindof an AIR-only solution- but can ANE be used to achieve multithreading today? i.e. have an extension which kicks off a thread to process a bunch of stuff and then returns control back to the main app? (I haven’t played with ANE yet)

    Monday, July 2, 2012 at 9:45 am #
  66. Vemilyus wrote:

    DavidK: In ANEs you can use whatever APIs that are available in the programming language (C/C++, Java, Objective-C, …), including threads if they are supported (e.g. POSIX Threads). But using those threads would enable you only to execute threaded code in your ANE, not code of the using SWF file.

    Wednesday, July 4, 2012 at 4:42 pm #
  67. DavidK wrote:

    gotcha… thanks :)

    Sunday, July 8, 2012 at 9:43 am #
  68. Awesome, can’t wait. A friend of mine was showing me how native android apps use threads to process UI on primary thread and other work on separate thread to allow for fast transitions (perceived) between views. Do you think adobe will change air runtime and incorporate workers to speed up view transitions and creation of objects on pushed view?

    Wednesday, July 11, 2012 at 9:39 pm #
  69. Je trouve ça trop compliqué.. :S Des messages channels etc.. un SWF séparé devrait simplement pouvoir accéder à la mémoire de domaine du SWF appelant de façon totalement transparente. il faut juste réinventer un nouveau genre de localConnection simplifié bidirectionel (aussi simple à implémenté qu’external interface). on transmet la data en param, ce n’est qu’une référence, et le SWF slave sait directement aller chercher la data dans la mémoire de domaine du master.

    Le fait que ce soit au runtime que le worker soit créer.. oui et non.. pourquoi ne pas plutot inventer un nouveau format, le SWP (pour process) c’est un SWF sans displaylist, sans stage, sans defineJpgTag, etc.. Juste un SWP qui lancera une instance séparée de player.exe, on aurait un multithreading (multicore) by OS relay.

    Au niveau du compilateur, le simple fait qu’une classe extends process, cette classe serait compilée en SWP à coté du SWF Main application. au moins, ce serait très souple! on pourrait faire des process, un fichier process pourrait être redistribuer (comme un composant) et sur le meme mécanisme, on pourrait choisir de faire communiquer un SWF avec 1 ou plusieurs SWP, mais aussi plusieurs SWF (si besoin de diplayList).. bref, ça me semble plus souple et + facile à coder.. Enfin, ce n’est que mon avis.. :-)

    Ca fait un moment que je cherche à faire du MT ou du non bloquant.. j’utilsie actuellement localConnection ou externalInterface. Ou j’utilise un timer pour faire du script release en monoThread..

    Saturday, July 14, 2012 at 11:41 am #
  70. The Flash Player beta is droped! i tryed the Worker feature and i make a tutorial (in french)


    good Luck ;)

    Wednesday, July 18, 2012 at 3:51 pm #
  71. Polaco wrote:

    As others has mentioned probably Java programmers like me, I feel sad about this implementation of workers. In my opinion this is more weak, harder and tricky to use than Java multithreading implmentation (a vm with several years old). Also 7mb per worker is a lot of memory to pay for each worker, loading an external swf with the worker code quite weird and messy. I understand that you are under a schedule and have to deliver something but would really love to see Workers improved in a future. I know many Java guy may laugh by looking at this implementation. Thanks a lot for your efford and my best wishes for FP dev team.

    Thursday, July 26, 2012 at 6:18 pm #
  72. Polaco wrote:

    @Thibault “Also, we decided to do this because we know that most AS3 developers are now seasoned developers and know what they are doing, so we wanted to give them more power…” You can’t ban a capability due you have dummy programers since you have dummies as experts too. That’s no excuse, you can’t say that multihtreading wasn’t provided due to that, you should provide as many capabilities as you can to AS3 and FP let programmers grow and handle it later. Also you are an incredible and brillant developer and it looks to me that this multithreading implementation is a bit below your marks. I really hope you offer a Java like way in the future if you are targeting games and enterprise apps and also if you want to be seriously consider in the field of multithreading. My best wishes and thanks you.

    Friday, July 27, 2012 at 10:07 pm #
  73. Here demo with box2d on workers


    Sunday, August 19, 2012 at 1:04 pm #
  74. By the way can we lower priority of the Workes or set on pause?

    Sunday, August 19, 2012 at 1:06 pm #
  75. Terry Corbet wrote:

    Posted here in response to your message on the esdot site: http://esdot.ca/site/2012/intro-to-as3-workers-part-3-nape-physics-starling in so much as it is no where publicly possible to find that official address of the Product Manager. As you asked for information concerning the ways in which communications concerning Workers was mishandled, I will try to provide helpful facts in this 2×4 inch box.

    1. As to the non-response to requests for information concerning Workers this thread: http://forums.adobe.com/thread/1037293?tstart=0 demonstrates as much as any other I could site on the simple fact that Adobe does not assign a responsible person to promptly reply with facts. Or, you could simply review the incorrect statements concerning Workes provided by your associates Jens Loeffler and Diane Helender. I would provide the link to the discussion concerning Lee Brimlow’s version of your example of MP3 conversion, as it appeared until he took it down a couple of days ago.

    2. As to non-responsiveness with bug bug reports and your last-minute discovery of a security problem with shareable Byte Arrays: https://bugbase.adobe.com/index.cfm?event=bug&id=3298228

    3. As to whether only prerelease members, not ordinary developers are given any support: https://bugbase.adobe.com/index.cfm?event=bug&id=3308241

    4. As to whether or not even pre-release documentation can be used to plan development I cannot find the URL in which it was reported that any attempt to use the File package classes in a background thread raised a security error. I know it was a Flash person who was only surprised that the limited support for such things in a Flash application would show up. Had this been worked on in an AIR context — for which there is not a single example — the inability to perform file operations would have been a complete show-stopper.

    4. As to whether or not any testing was done on AIR implementations: https://bugbase.adobe.com/index.cfm?event=bug&id=3317078 to which I have attached a complete regression test bundle.

    5. As to the disconnect between the Flash and AIR implementations which is probably almost synonymous with the disconnect between games and mission-critical applications, the wonderful treatises released as documentation on Workers, which most certainly must have been around for weeks, suggesting that using the concurrency/locking primitives provided by a database to replace the sharing of Wav and MP3 encodings of a Sound through a pipe implementation of the ByteArray is a classic that everyone who has spent the last forty years writing software will certainly cherish. Lee, on your behalf, in his dog-n-pony show yesterday, pointed to the win-win of Adobe signing up with open source projects. I think if you had been transparent with the specifications for Workers, shared the architectural alternatives being considered, written the test plan before one line of implementation code was started, allowed a proper test cycle so that all the constituent users of the facilities could provide feedback, and made sure that questions were answered promptly and most importantly, correctly, it might have come off better.

    The very fact that there is no published email address for corresponding with the Product Manager, that you have to look at multiple forums and databases to get a handle on the state of your product, and that I have to put all this in a 2×4 window is all you really need to know in order to know that that is not the way to run a railroad.

    Saturday, August 25, 2012 at 12:18 am #
  76. Thibault Imbert wrote:

    Hi Terry,

    Thanks for the links and details. As I said on Shawn’s blog, the lack of documentation around Workers is a mistake and we will fix it. I would still not recommend using SQLLite for AIR to simulate shared memory and wait for full support with synchronization provided through Condition and Mutex APIs.

    You can find my email in the About section of this blog:

    You can always email me to ask anything. I will answer.

    You can also always tweet me on Twitter:

    If you follow me you will see that I answer almost every question I get. I actually talked recently about the shared memory topic.

    Finally, I have always spent lots of time on documentation, when we released Starling, I released a book was for free for developers:

    Also, when Flash Player 9 was released I published a free book available for download:

    So really, I care about the documentation issue and will do my best to fix this in the future.

    Thanks again for the feedback Terry.


    Saturday, August 25, 2012 at 2:53 pm #
  77. Marcus Baffa wrote:


    I have a Flex application that has a Dispatch Queue that has to be accessed by multiple workers. The access obviously must be sinchronized. This a typical case of critical region.
    I need mutexes to sinchronize the access. Where can I find information and tutorials on Mutexes and Conditions ?
    Thanks in advance

    Monday, August 27, 2012 at 7:58 pm #
  78. WilliamX wrote:

    This was the most annoying thing to do, and something SL or iOS didnt have problem with. It looks kind of the BLOCKS feature in Objective-C. This should have come out 5 years ago at least. Goodbye Monkey-Chuncking.

    Thursday, September 6, 2012 at 6:37 pm #
  79. Martin V wrote:

    Hi Thibault,

    That sounds really exciting. I’m coming from ps3 / xbox360 multithreaded engine development team and cannot wait to test this solution in flash.

    I thought I’d mention the way I’d want to use it and get some feedback on how to do it.

    When using worker threads in the past, there was a queue of job descriptions stored in memory. Main thread (or any thread that needed to submit a job to another thread) would simply create new job description (a class holding data that needed to be processed), and add it to the queue (concurrent access to the queue would be managed by mutex).
    There would be few worker threads created (usually one per core), and each time a job was added to the queue, they would be messaged by an event to wake them up in case they’re idle. Then they’d access job queue, pull the next job and work on it.

    With this system usually main thread would generate say 100 jobs each frame, and simply add them all to the queue, and then it would loop over them and wait for results (that’d block in case workers haven’t finish that job).

    Base on your description above, I think this should be doable in AS3, but after using flash for few hours only, I would not mind some feedback on it.

    Wednesday, September 19, 2012 at 12:40 am #
  80. Martin V wrote:

    Perhaps I should add one more thing. Based on your example, I’m sure I could do it the way that each time job is created, instead of adding it to a queue I would send message to a specific worker, which would later pick it up and process. But this means I would need to do thread balancing by deciding which worker gets the job.
    I’d prefer a solution where I don’t need to do it, as I don’t care which if the worker executes the job – I’d want first idle worker to pick it up.

    I could send the same job to all workers, and first one that starts to work on it would write flag to some shared memory accesses using mutex marking it as taken, so other threads would skip over it. Is this the way to do it?

    Wednesday, September 19, 2012 at 12:46 am #
  81. Will the multi-threading allow the threads to be run on seperate cores in a multi-core machine?

    Thursday, September 20, 2012 at 10:29 am #
  82. I’m wondering if anyone know why inside a worker ExternalInterface.available is returning false.

    Is this voluntary ?

    Thursday, October 11, 2012 at 11:32 am #
  83. Peter wrote:

    fuck this. I hate to say it: ADOBE YOUR WORKERS SUCK BIG TIME!!!!!!!!!!!!! AND YOU KNOW IT.

    Friday, October 26, 2012 at 11:37 pm #
  84. Thibault Imbert wrote:

    Hi Peter,

    Can you give some more details on why? :)


    Saturday, October 27, 2012 at 12:31 am #
  85. Peter wrote:


    All you need is StartCoroutine(function), StopCoroutine(function). I was looking forward to this, like it is unuseful for me. Hope they change it.

    Saturday, October 27, 2012 at 12:59 am #
  86. Peter wrote:

    and also serialization between workers is a bottleneck in my opinion. sry for double comment.

    Saturday, October 27, 2012 at 1:00 am #
  87. Henrik wrote:

    Hi Thibault,

    It’s a while since you posted this. Do you have any updates on mobile workers? Even an idea of if it is something to expect during the first half of 2013 (AIR 3.6?) would make me happy!


    Saturday, November 10, 2012 at 11:52 am #
  88. Andrew wrote:

    I can successfully utilize Workers in Flash CS6 when publishing for desktop 3.4
    worker = WorkerDomain.current.createWorker(Workers.BackWorker);

    The same code however when published for Android 3.4 or 3.5 or Desktop 3.5 does Not work.
    The worker is null.

    I have heard others having issues with 3.5 so will let that go for now.

    But how about Desktop 3.4 vs Android 3.4 ? Is there any permissions specific to workers that need to be included?
    I have included the worker swf in the APK and also tried Not including it.

    Any help appreciated.

    Monday, November 12, 2012 at 2:37 am #
  89. j@j.com wrote:

    long time old school flash developer coder here… I admit I almost gave up on flash because of HTML5 and lack of support on IOS but after seeing this I have renewed interest and am happy I can most likely use my skills without them having went to the dustbin of programming langauges. thank you!

    Tuesday, November 13, 2012 at 5:24 pm #
  90. wj wrote:

    I have been working on some major tooling for developing games for my current company and we pretty much had to stop it due to the way these workers are implemented.

    * Having multiple threads running is too memory intensive.

    * Bottlenecks in shared memory.

    * To awkward to use, its time consuming for any large project that actually needs multiple background workers that support a multitude of features. (In Java we would simply have each feature as a single class, nice and simple and understandable instead of messaging all over the place and we can queue them, schedule them in seq/par etc easily)

    * Java workers are way simpler.

    * Inability to access main domain definitions from a worker, we wanted to emulate some features of Unity 3D Annotated scripts that you can drag into an inspector, it was going to be real time etc. But required heavy use of AOP and ByteCode which locks the IDE for 4 to 5 seconds and that was unacceptable and we cant do it in threads cleanly. We knew if we went further we could have wait times of up to 10 seconds waiting for AOP.

    We are now investigating building our IDE in Objective-C or Java instead of AIR using workers which is a shame because we wanted to make it available to a wide audience but seeing as we all use macs in the office we are just going to build it for mac.

    And instead of a multi threaded framework for our game SDK we are simply going to load an XML file produced by our external tooling and the only threading support we will add to our SDK is for loading resources in the background.

    It’s a big shame really, we could have built such an amazing tool if we had access to real threading that was similar to the Java implementation, we cant spend twice the amt of time working on it, that’s just not worth it either.

    Anyway that’s just my 2 cents, I’m an avid fan of Flex and have been using it ever since 1.0 but it really needs to come to terms with the fact that every language has good/bad programmers and you cant hold our hands. Some of us want to build highly complex powerful tools but you are restricting us and forcing us onto other platforms.

    My company is now considering Unity 3D for all it’s game development as well which I’m not against however I much prefer building GUI’s in flex but I understand where management is coming from, using Unity would increase productivity / throughput and allow us to build more powerful games that run on every platform as well. I hope flash picks up the slack and gives us more powerful features we can actually put to good use aside from loading images and data in the background.

    Thursday, November 15, 2012 at 11:53 am #
  91. Sean wrote:

    Any news on Workers on mobile?
    It’s the one thing Adobe need to add so we can develop high end games for mobile…

    Thursday, December 6, 2012 at 5:46 pm #
  92. Peter Herz wrote:

    While this is definitely cool and long overdue ‘native’ development for AS3.. I wonder for those that are looking to achieve the same thing but without requiring FP11.4 clients only.. and perhaps they want to do this but with mobile clients which this example doesn’t support.. then they use as3-commons async or greenthreads lib on google code btw.

    Sunday, December 23, 2012 at 7:04 pm #
  93. pol2095 wrote:

    still no mobile workers in air 3.6, any news on mobile Workers ?

    Thursday, February 14, 2013 at 1:01 am #
  94. YopSolo wrote:

    no mobile workers in air 3.7 ?

    Monday, April 22, 2013 at 3:02 pm #
  95. did worker support in Flash Builder 4.6 since i tried to add it but it doesn’t work ?
    If supported ,firstly , how to implement it in Flash Builder and using it . secondly , did it support for flex project or Action Scriptproject or both ?

    Monday, June 24, 2013 at 10:29 am #

Trackbacks/Pingbacks (12)

  1. Multithreaded Flash Player… | Skinkers on Monday, June 11, 2012 at 2:03 pm

    [...] There is a great article on byteArray about it :http://www.bytearray.org/?p=4423. [...]

  2. [...] http://www.bytearray.org/?p=4423 [...]

  3. Prozessor ansprechen - Flashforum on Friday, June 29, 2012 at 10:03 am

    [...] [...]

  4. [...] of Adobe’s leading engineers have posted the following video in his walk through of how it’s most likely going to work with workers in Flash [...]

  5. ActionScript Workers 0 « AKABANA on Tuesday, July 17, 2012 at 3:52 am

    [...] http://cuaoar.jp/2012/06/actionscript-1.html http://www.bytearray.org/?p=4423 [...]

  6. ActionScript Workers 0 « AKABANA on Tuesday, July 17, 2012 at 3:52 am

    [...] http://cuaoar.jp/2012/06/actionscript-1.html http://www.bytearray.org/?p=4423 [...]

  7. AS3多线程快速入门(一):Hello World[译] | DomLib on Wednesday, August 15, 2012 at 6:58 pm

    [...] 简单说,Worker就是在你主SWF里运行的另一个SWF程序。想要更深入一点的了解,请移步:Thibault Imbert的这篇牛文。 [...]

  8. Aymeric Lamboley » Citrus Engine V3 Beta2 on Tuesday, August 21, 2012 at 5:31 pm

    [...] Workers can provide a huge performance boost. Take a look on this example using Nape & Starling. [...]

  9. [...] Flash Builder的4.7支持的能力,创建和调试ActionScript工人的。现在,你可以写代码,平行并发任务。有关详细信息,请参阅先睹为快:使用ActionScript工人的并发和使用ActionScript工人。 [...]

  10. Lo nuevo en Flash Builder 4.7 | AUG Venezuela on Wednesday, August 29, 2012 at 2:48 am

    [...] Uno de los aspectos más esperados era el nuevo compilador “Falcon” ahora llamado ASC 2.0, que incluye el resaltado de errores en el código en “tiempo real”, haciendo uso del nuevo soporte a 64 bits de la herramienta y su manejo de múltiples capas de procesamiento. Además el desarrollo para dispositivos móviles se verá beneficiado por el nuevo simulador y el “debugging” usando USB para iOS, la generación de versiones orientada a múltiples plataformas y la concurrencia en ActionScript (ActionScript Workers). [...]

  11. RIA212 » Blog Archive » Lo nuevo de Flash Builder 4.7 on Wednesday, August 29, 2012 at 2:49 am

    [...] Uno de los aspectos más esperados era el nuevo compilador “Falcon” ahora llamado ASC 2.0, que incluye el resaltado de errores en el código en “tiempo real”, haciendo uso del nuevo soporte a 64 bits de la herramienta y su manejo de múltiples capas de procesamiento. Además el desarrollo para dispositivos móviles se verá beneficiado por el nuevo simulador y el “debugging” usando USB para iOS, la generación de versiones orientada a múltiples plataformas y la concurrencia en ActionScript (ActionScript Workers). [...]

  12. bank lån on Friday, May 10, 2013 at 11:39 pm

    bank lån…

    A sneak peek: Concurrency with ActionScript Workers – ByteArray.org…