Adobe's Flash player run time environment does not support multi-threading; except for very specific external interactions. Flash player uses an ancient frame-by-frame single threaded monolithic execution model. This means that drawing in the UI and handling user interactions are directly blocked by data processing and other heavy lifting work.
The Flex framework's UIComponent implements a standard invalidate/update pattern that relieves much of the UI's drawing impact in well written components. UIComponent also has the callLater method. However, there's no equivalent for simple back-end data processing.
The "Thread.as" ActionScript class in the Flex Project linked below can be used by any Flex class to implement a "threaded" worker. Simply create a "worker" function that does a single unit of work; usually from a queue of pending work. Then create an instance of this Thread class, supplying the worker thread as the first argument. Remember to keep the worker thread very lightweight, doing as little as is absolutely possible.
The worker function will be called repeatedly, until it returns a "true", indicating that the work is complete. The logic of this class will take care of exactly when to call the worker function, so as not to impede the timely advancing of the Flash Player's frames. Thus the appearance of "background processing" while the user is still able to interact with the UI.
You can optionally provide a "work complete" function, that is called once at the completion of work.
This implementation also takes multiple parallel executing threads into consideration. Note that the allotted time for execution is divided equally among all executing threads. However, you can still choke out the available computing resources with too many threads, or a worker function with a long execution time.