Async Action Groups - Known compiler limitations

I am looking to optimise our build in certain places by using Async Action groups and I see there is a comment in the help:

Some compilers (such as the Delphi compiler) and some other tools may lock certain files and a second instance may not succeed.

I am generally intending to use different tools concurrently to avoid unexpected issues with running multiple instances, however the Delphi compiler would be the one exception, so I just wondered if you know any more details about which files it locks to save me some detective work with Process Monitor

Hi Simon

The problem with Delphi is that it locks dcp and dcu files for exclusive use, so when two instances of the delphi action under and async group you will see strange errors reporting that it cannot find files like system, sysutils etc. This issue was reported to Borland/CodeGear/Embarcadero in the past (I seem to recall during the D2007 beta) so I’m not sure if it has been addressed in later versions.

The other issue is that compilers are both I/O and cpu bound, and in many cases it is slower to run them in parallel than it is to run them serially.

The Async action group is the most abused action in FinalBuilder, we have seen some customers projects where they have 50+ threads running by nesting async groups. Generally you should stick to 1 thread per core, any more than that you will need to ensure you mix io bound actions with cpu actions.

Hi Vincent

Thanks for the information.  I spend quite a bit of time optimising multi-threaded applications so am thankfully aware of the trade offs from the processor right down to the hardware. 

I basically intend to have one thread per core and to run tasks in parallel that won't conflict over shared system resources so I should see a reasonable gain.  For compilation in parallel that will be via mostly seperate file I/O routes (the compilers' exectuables should be cached) and based on your information I will probably switch to running Visual Studio in parallel with the Delphi compiler to avoid any nasties. 

>  we have seen some customers projects where they have 50+ threads

Unless they've got a heck of a lot of cores and a large SSD array I think that's a bit keen

Simon