Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Revamping Code Completion with little changes
grv575:
I don't think it should be a singleton. The pool of threads executes a queue of tasks, so independent modules (compile, code completion) would not want to wait to even start to execute if the other module has all the available threads occupied...
So multiple thread pools looks needed. Is it possible to do something like:
#define THREADPOOL_COUNT 2
cpus = g_ThreadPool.GetCpuCount();
g_ThreadPool.SetConcurrentThreads(cpus / THREADPOOL_COUNT);
Urxae:
--- Quote from: grv575 on August 22, 2005, 10:59:48 pm ---So multiple thread pools looks needed. Is it possible to do something like:
#define THREADPOOL_COUNT 2
cpus = g_ThreadPool.GetCpuCount();
g_ThreadPool.SetConcurrentThreads(cpus / THREADPOOL_COUNT);
--- End quote ---
You do realize that would round to 0 if there's only one CPU, right? :?
zieQ:
--- Quote from: grv575 on August 22, 2005, 10:59:48 pm ---I don't think it should be a singleton. The pool of threads executes a queue of tasks, so independent modules (compile, code completion) would not want to wait to even start to execute if the other module has all the available threads occupied...
--- End quote ---
Well, could I suggest you to read to links I provided? If there are too many threads, even if you dispose of another pool, your tasks will wait for the processors to be available since they are already busy with the other pool btw, and you will also have a performance penalty. One thread pool make it easier to get optimal performance whatever the task could be (compile, code completion). Remember, the thread pool has a queue of tasks: if you don't flood the pool with tasks, independent modules could execute concurrently with maximum performance. We may assign a priority to tasks but that's not that easy to make it work well. Your solution is worse: you dispose of half the computing power for each pool, with half worker threads going idle most of the time due to inactivity of the pool! Nonsense.
Mandrav, I don't see why we may delete tasks since they are supposed to be executed for a short time? It's not safe I think, since once the task is completed, the pointer could have been deleted!
grv575:
--- Quote ---Your solution is worse: you dispose of half the computing power for each pool, with half worker threads going idle most of the time due to inactivity of the pool! Nonsense.
--- End quote ---
Yeah, I wasn't thinking. I guess only 1 pool makes sense. It's not like there's any other tasks besides compilation that should require long completion times anyway.
--- Quote ---Mandrav, I don't see why we may delete tasks since they are supposed to be executed for a short time? It's not safe I think, since once the task is completed, the pointer could have been deleted!
--- End quote ---
You're going to want some way to signal the thread to terminate safely to cleanup resources (like say when the user closes the app).
rickg22:
--- Quote from: grv575 on August 23, 2005, 06:16:47 am ---You're going to want some way to signal the thread to terminate safely to cleanup resources (like say when the user closes the app).
--- End quote ---
ManagedThread does that :D. It keeps a static flag, and each class can point to an additional flag that tells them to terminate.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version