Tate blogged about Async Action Groups a few weeks ago, however there is a lot of confusion about how they work amongst the beta testers(something we need to address in the documentation!). I'm going to explain here exactly how they work and discuss some of the limitations inherent in threaded builds.
Lets take a look at an Action List with an async group :
In the above example, Action 1, Action 2 and Action 3 will be started simultaneously. Each immediate child action of the Async Group is treated like an action inside their own action list, and this is in fact how it is implemented. The actions are mapped onto a pseudo action list object and then the pseudo action list object is executed in it's own thread with it's own execution engine.
If we look at the above list, the general execution order will be something like :
(in thread 1) Action 1, Action 1.1, Action 1.2, Action 1.2.1
(in thread 2) Action 2, Action 2.1, Action 2.2, Action 2.2.1
(in thread 3) Action 3, Action 3.1, Action 3.2, Action 3.2.1
The actual execution order (ie the real time execution order) would probably be completely different depending on which actions are used and how long they take to execute, however Action 1,2 & 3 will always start at pretty much (give or take a few milliseconds) the same time.
So now we know how Async Groups are supposed to work, lets mull over some of the implications of using Async Groups and look at some of the limitations. Just like threading in your application code, Async Groups are no silver bullet. Having two or more actions running in parallel will not necessarily translate into reduced build times. Your milage will vary, depending on whether your actions are I/O bound, or CPU bound. Running two cpu bound actions in parallel will probably increase the time they take compared to running them in serial. The same applies to i/o bound actions. So the smart thing to do is run a cpu bound action in parallel with an i/o bound action. Of course, if you are running your builds on multi-cpu machines with very fast hard disks and gigabit Ethernet then these rules go out the window.. and trial and error will prevail.
So what limitations are there with Async? Well, some actions need exclusive access to a resource, for example the Visual Source Safe actions change settings in the ss.ini file before running the source safe command line tool. These settings need to be changed for the command line tool to give us the behavior we require. So what happens if we execute two source safe actions together? The results are unreliable at best. In the current beta (build 31), we don't have anything to prevent this from happening. In the next build we upload, we have implemented a generic resource locking scheme in the execution engine, so that when an action is executed, it can indicate whether it needs a resource lock or not. The source safe actions will now provide this indication, and the net effect is that the source safe actions will be serialized, even if they are running in an async group. This applies only to source safe actions using the same srcsafe.ini file (ie vss database). If another source safe action is using a different database then that action would not require serialization. The same applies to the CD Burner and Create ISO actions. In our tests, we found that the cdburner library we use is not thread safe and so requires locking. In the next few weeks we'll be testing all the actions in Finalbuilder for thread safety and implementing resource locking as required.
Another limitation is that you cannot use the “Run Actionlist“ and “Include FinalBuilder Project“ actions under an Async group. The reasons for this are complicated. If the same actionlist was executed multiple times, it would require multiple instances of the action list to avoid re-entrance issues, and that brings with it a whole host of other related gotchas. While I do plan to spend some more time investigating enabling these actions under Async Groups, I'm not expecting that this will happen before 4.0 is released.
When we looked at adding the Async Group action during our planning for FinalBuilder 4, we figured people might potentially achieve 10-15% faster builds. So far, the feedback from beta testers has proven that to be the case. In our own builds, we achieved around a 5% boost, on a single cpu VMWare virtual machine. We did try the virtual smp support in VMWare 5.5 beta, however it actually resulted in slower builds. We'll try again when VMWare 5.5 is released.
v.