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

Alan Ezust alan.ezust at gmail.com
Wed Oct 24 17:40:17 CEST 2012

On Wed, Oct 24, 2012 at 1:08 AM, d3fault <d3faultdotxbe at gmail.com> wrote:

> On 10/23/12, Alan Ezust <alan.ezust at gmail.com> wrote:
> >
> > http://www.ics.com/designpatterns is one place where you can see the
> book's
> > contents and download the code examples. It requires you to
> register/login
> > but it's free.
> >
> Which example are you referring to? Life or PrimeThreads? I read the
> whole chapter on QThreads and QtConcurrent...

PrimeThreads is the example that is rewritten using QThread and also

> I stopped reading Life's source when you called
> QtConcurrent::blockingMappedReduced from the main window class (these
> aren't the designs I'm looking for).

The duration of each call to blockingMappedReduced is not very long in that
The main point of that example is to show a puzzle that can take advantage
of a map/reduce.

> I am pretty sure the reason your QtConcurrent version of PrimeThreads
> is significantly faster than the QThread version is because:
> a) QtConcurrent pre-generates the list of numbers to check against ahead
> of time
> b) The QThread version QMutex-grabs the next number each time
> c) Generating prime numbers scales horizontally... though I guess your
> for loop generating QThreads should too... so maybe (c) shouldn't be
> here

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

But the time to generate the list of numbers (a) is also being taken into
account in the measurements.

> I'm inclined to believe that QtConcurrent::filter() uses something
> similar to QMutex behind the scenes... but maybe not? Maybe
> QtConcurrent::filter() is more optimized while still providing similar
> functionality (without using QMutex specifically)? I don't know how
> it's implemented. However the tests already don't seem fair.

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

> For the example I'm creating I am not demonstrating resource sharing
> so I'm not going to use QMutex anywhere...

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

> and I can't determine a
> reason that a single long running (non-horizontally-scaling) backend
> would benefit from using QtConcurrent (especially since with
> QtConcurrent it will just be 1 QThread pulled out of a QThreadPool
> anyways, right?).

Then you can probably do it all with only one thread and an event loop.
Why do you need another thread at all then?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121024/05e90a62/attachment.html>

More information about the Interest mailing list