Excel-DNA allows different approaches that you might find useful:
- you can make UDFs marked as 'thread-safe' to use Excel's support for multithreaded calculation - in this case Excel controls the threading, and will call your UDFs concurrently from different threads,
- you can use the asynchronous functions in Excel-DNA (possibly using the .NET 4 Task API) to start the work on the grid, and upon completion notify Excel to recalculate,
- you can use the Reactive Extensions support in Excel-DNA and build a calculation pipeline on the Rx library ,
- you can use the support for Windows HPC clusters built into Excel 2010, using Excel-DNA to host the managed code in the client and on the cluster nodes.
In none of these cases would it make sense to call into Excel VBA - Excel will always ensure that the VBA code is running on Excel's main thread.
If your function code is in VBA, you might consider using VB.NET for your Excel-DNA add-in, instead of C# - it might make your move to .NET quite easy. You could also make a mixture of C# and VBA in your managed Excel-DNA add-in.