[Interest] Heavily Commented Example: Simple Single Frontend with Two BackendsLow,

[d3fault]

Time to split this thread. Since they took "Hi," (our spot!), we'll
take "Low," haha

On 10/24/12, Alan Ezust <alan.ezust at gmail.com> wrote:
> There are LOTS of reasons why PrimeThreads is slower when it manages its
> own threads and
> creates mutexes.   You listed some of them there, I listed others in my
> book.
>
> But the time to generate the list of numbers (a) is also being taken into
> account in the measurements.
>

Precisely. Generating a list of numbers in one tight loop is going to
be MUCH faster than locking/unlocking a QMutex during every iteration.

>
> "fair"? I don't know how i could possibly make it "fair" when the
> qtconcurrent one removes the need
> for QMutex.
>

When you state that QtConcurrent is much faster than QThreads, your
tests between the two need to be fair. I don't use a mutex or any
other primitives lower than QThread in my example.


>
> You were using volatile in your example when you should have been using
> something higher-level such as
> an atomicInt or a mutex.
>

Nope, that was someone else asking a question. I tried and failed to
answer it... and it sparked that "Hi," discussion that hijacked this
thread haha :-P.


>
> Then you can probably do it all with only one thread and an event loop.
> Why do you need another thread at all then?
>

Because long standing heavy lifting backend threads do exist, and the
purpose of the example is to create a reference for doing it cleanly.
Glad I made this thread else I never would have gotten the
stack-object-within-run idea (thanks to all those who contributed to
that, directly or indirectly).


I think I'm just going to stick with QThread. "Choose the right tool
for the job".

d3fault