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

d3fault d3faultdotxbe at gmail.com
Wed Oct 24 20:31:25 CEST 2012

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".


More information about the Interest mailing list