anon (a@b.c) on 8/26/09 wrote:
---------------------------
>JasonB (no@spam.com) on 8/26/09 wrote:
>---------------------------
>>Richard Cownie (tich@pobox.com) on 8/25/09 wrote:
>>---------------------------
>>It sounds like you're really programming in C with a little bit of C++ thrown in
>>and very little encapsulation. That's perfectly valid, but it isn't very representative
>>of how easy or difficult it is to thread other types of code and therefore whether
>>people only "occasionally" manage to write correct multithreaded code.
>
>I'm not so sure Jason. It sounds like you and Richard have fundamentally different
>types of applications that are or are not amenable to different sorts of parallelism.
>Your app is simpler, has shallow interlinking of data structures and often just
>has the objects flat in the collections classes. Life is much simpler from a parallelism
>perspective. Richard's app has complex highly interrelated data structures where
>one can follow pointers deeply embedded from one end of his object graph to the
>other. His app is much more complicated to parallelize at a fine grain. I don't
>think this is due to the lack of prowess of his team in encapsulation skills or
>parallelism foresight imparted into the code. For some problem domains you have
>to believe they are not as applicable to be sped up this way.

Just to take a step back and put my comments in perspective, my original response and subsequent defence of multithreading was in the context of the following comments by Richard:

By "lightweight threads" I mean any scheme with multiple
threads of control accessing data structures in shared
memory.

There's a good paper on "The Problem With Threads" which
goes into considerable detail on the many ways this is
a bad idea. Basically even for apparently trivial
programs it's desperately hard to enumerate all the
possible sequences of interactions and prove that all
are correct. I suppose occasionally people manage to
write correct threaded code, but mostly it has lurking
bugs. And then the problem is aggravated by the fact that
there's no good way to reproduce a bug because the
the threaded program doesn't execute things in the same
order each time.

So as for whether there are cases where threads are
"easy to use and cause no problems at all", my personal
view is that while in theory it's possible, in practice
I've never seen any such case - and on the contrary, the
few times I've encountered threads they've caused me big
trouble (even though they weren't even in *my* code).
YMMV.

In essence, he has based comments like "I suppose occasionally people manage to write correct threaded code, but mostly it has lurking bugs" on his personal experience and I've been arguing that his personal experience is insufficiently representative to make statements like that.

I have repeatedly stated that I have no idea how hard or how easy it would be to thread his code -- merely that multithreading can be a far easier option with much less effort required in the right circumstances, and can have much better performance to boot -- again, depending on the circumstances.

We have algorithms and serial suboperations in our parallel algorithms that we have not been able to parallelise at all, so I am well aware of how hard it can be. In fact, the need to quickly switch between parallel suboperations and serial suboperations over and over again is one of the reasons why I see multithreading as such a big win in some of our cases, because copying that same data back and forth between processes would be a significant overhead.

At the same time, the most efficient parallel case we have is our batch processor that can process an entire project serially on each core, with absolutely no communication required between projects because each is independent. In that case there is no disadvantage to multiprocessing vs multithreading. But when we have a user interacting with the software waiting for an operation to complete, it's no good telling them that if they were attempting to do the same operation at once on four different projects the throughput would be really good, they just want the operation to complete as quickly as possible, and for us multithreading is the answer in those cases.

So just to restate my position: multithreading can be a much better and more viable option than Richard suggested, and that has been my point all along.