Review Request: Implemented multithreading in KFileItemModelSortAlgorithm

[Frank Reininghaus]

Hi David,

2012/12/8 David Faure:
> On Thursday 25 October 2012 13:48:55 Frank Reininghaus wrote:
>> I can't really believe that a recursive implementation is slower than the
>> loop-based one you posted here... (provided that you make sure that the
>> number of invocations of QtConcurrent::run() is equal to the number of CPU
>> cores, which means that you always have to do the second recursive
>> sort()-call without QtConcurrent, as I said).
>
> Hello from the "this doesn't make sense" police.
> The above doesn't make sense :-)
>
> QtConcurrent is perfectly capable of running a runnable in the main thread,
> and does so automatically.

Yes, I know. But what I had in mind is the case of more than 2 CPU
cores. Let's assume that we have 4 cores, and that all calls to the
sort function are done using QtConcurrent.

The main thread (let's call it thread 1) calls the sort function twice
using QtConcurrent. These are run in threads 2 and 3, which sort the
first and second half of the list, respectively, and the function in
thread 1 waits for them to complete until it can perform the merge.

Now the sort function is running in thread 2 and 3, and each of them
uses QtConcurrent twice to invoke the sort function recursively.
That's the idea of 4-way parallel Mergesort - let each core sort one
quarter of the list, and then merge them.

I can see that the QtConcurrent invocations from thread 2 will run in
a new thread 4 and the main thread 1, but I don't know if QtConcurrent
is clever enough to see that threads 2 and 3 are blocked waiting for
their QtConcurrent calls to complete, such that it can assign thread
3's sub-tasks to thread 2 and 3. You might have more insight into this
;-) I would try it, but unfortunately, my CPU has only 2 cores.

Best regards,
Frank