Task Queue that executes Task asynchronous

I need to queue tasks that do something to make sure they execute in the right order. They should run asynchronously and the next task should start when the previous is finished.

Does JUCE support something like this?

Does the ThreadPool with one thread guarantee that the work is processed in the right order?

Edit: It looks like the ThreadPool does not process the requests in the order he received the jobs.

Edit2: ThreadPool works as expected.

juce::MessageManager::callAsync will call the lambda you give it at some point in the future on the message thread, and AFAIK the tasks will be executed in order.

Thanks for the answer. If I understand right the MessageManager runs things on the message thread and it can also lead to deadlocks.

I like to load samples in the asynchronous code and I want to make sure they load in the right order.

I did something similar using a TimeSliceClient.

I add samples to be loaded one by one to a queue and start the TimeSliceThread if necessary, it then processes the queue (albeit in FILO order, but would be trivial to implement as FIFO), loading a 16kb chunk at a time via an AudioFormatReader in useTimeSlice() (I should probably try to optimise the chunk size before release).

Whilst loading I return 0 from useTimeSlice so that the next call will be scheduled asap, and return -1 once the queue has been fully processed, which stops the TimeSliceThread.

A ScopedLock to make sure any access to the queue is thread safe and it worked out pretty well for me, no issues that I’ve discovered thus far.

edit: returning -1 doesn’t stop the thread, it removes the client from the list of clients to be serviced by the thread, and I assume that the thread consumes little to no resources when there are no clients to be serviced :slightly_smiling_face:

Thanks for the info. I will try that.

After some more tests, it looks like the ThreadPool with one thread assigned works pretty well now and queues the tasks right. I wasn’t able to reproduce the problem anymore.