ThreadPoolJob - Proper way to notify caller


#1

In the ThreadPool api, I have a thread pool, and thread pool jobs. When I init the thread pool and start adding jobs from another class, what is the proper way in Juce to notify the caller that the thread has finished its job?

Say I have MainThread.cpp, which creates the ThreadPoolJob, and contains the ThreadPool pool object. How does MainThread wait on ThreadPoolJob to finish, and then resume processing?

Regards,


#2

The whole point of the thread pool is to process a task asynchronously. If you want the main thread to block until a job is done then why not just process the job on the main thread and bypass the thread pool entirely?


#3

In this case, there would be server threads all running tasks related to disk-based processing. These threads could number in the millions, distributed over a cloud or virtualization…

In this case, I have a situation where a server needs to be able to read and write to potentially thousands of gigabyte-sized files. I can’t have each server thread constantly making system calls to the OS to not only locate a file but get a file handle and associated streams. That’s why I have it abstracted this way, so I have a 1-1 relationship between file handles, and the only thing that’s multithreaded is actually the reads/writes - not the file lookups/handles. So I’m trying to re-use some things in order to keep system calls down, and since I didn’t want each running server thread to entirely do its own file IO, I abstracted the file IO into a service or a factory, rather than doing direct calls.

If I were ancient, and we still had the means, I would go as far in this case as to order the file operations by platter location, but we stopped doing that sort of stuff what seems ages ago. (It would in affect read in data just as the arm spins around that part of the platter, so at each pass the arm reads in continuously or writes - it’s ancient history these days).

So in this situation I’m just trying to keep system calls down by abstracting the file IO operations, and even though each thread must wait on the file IO, I don’t want, say, 100-1000 handles simultaneously to the same file.

There may be a better way to do this - I thought of maybe having the file IO just shared between threads and constant. But then that would make the filesystem single-threaded, and could slow things down (raid, cloud, virtualized storage, multiple disks, etc.)…

Let me know your thoughts.,


#4

I think in this case my last answer is best - having the server perform its CPU-intensive things in their set of threads and the disk performing file IO on its set of threads…

So next is on my task of measuring the throughput so I can automatically set the number of threads used in each operation. The thing is, with file IO, multithreading can have unexpected results depending on the architecture and what else is going on…

RIght now I’m using purely threadpools and threadpooljobs to take the place of what in Java would be threadpools and worker threads.

I’ve set it up so that the calling thread calls wait() and then gets notified by the threadpooljob when it’s done. That’s the part I was unsure about…