Richard Cownie (tich@pobox.com) on 8/22/09 wrote:
---------------------------
>Right. But that's just another aspect of "Windows culture",
>the fact that you have a bunch of customers stuck on 32bit
>and extremely reluctant to move forward.

Not just customers, vendors too -- I was extremely annoyed to find that the new HP laptop I bought a couple of months ago not only didn't come with 64 bit Vista (even though my previous one did, two years before), or have the option of coming with 64 bit Vista, but you can't even do an inplace upgrade to 64 bit Vista without wiping out everything! The fact that it comes with 4 GB of physical RAM while my older one had 2 GB is just ridiculous.

And this culture doesn't just affect 64 bit Windows -- can you imagine how hard it would be to get Linux or MacOS into one of these organisations? It's an "IT culture" that I don't appreciate, especially since I'm the IT support guy in my company. (When it's a small company even the MD has to fill many roles. ;)

I actually find the customers are more than happy to go 64 bits, it's their IT support departments that are the problem.

It's truly bizarre when you realise how similar the 64 bit versions are to the 32 bit versions. Most people don't know which they're using.

> The culture
>you work in - which includes the tools you use and the
>customers you have, and in my case having development
>spread across sites on three continents - exerts a huge
>influence on what might at first appear to be technical
>design decisions.
>
>One big reason I really don't want lightweight threads in
>my codebase is that making threaded code work requires following
>complicated rules which are not automatically enforced
>by current tools
>(e.g. don't access shared variables without holding a
>lock). And I know from bitter experience that it's
>impossible to get 100 people on 3 continents to understand
>complicated rules, to follow them, and to not mess with
>stuff they don't understand. That's a social and
>managerial issue, but it strongly influences the design
>choices.

Fair enough, and in those circumstances I might feel similarly because tools don't enforce the necessary rules.

However, if you're using C++ in the first place then you're already assuming a certain level of competency. :-)

One final point I would like to make: you've mentioned before the cost of major rewrites of code if a fundamental design decision was changed.

For us, using multiprocessing fits exactly into that category. A lot of effort would be required to make data structures amenable to easy partitioning and copying safely into a different address space, and no doubt it would introduce all sorts of new bugs.

Multithreading, however, is very simple. In the example I gave before, with the shared queue, the only writing that occurs into shared structures is putting results into two queues (one is the final completed queue, the other is the shared queue that items are read off of to see if they can be used to create other items). Everything else, which consists of maybe 100 MB of data in various structures, is only ever read and can be read safely from many threads at once.

That means all we have to do is put a critical section around a couple of lines of code that pop the item off the head of the shared queue, and a critical section around each of the two sections that insert items into the other two queues, and we're done -- thread-safe code. (Strictly speaking there are two critical section objects, one for each queue. You lock the one for the queue in question before doing an operation that will modify it. As I stated in my other post, locking and unlocking the critical section takes about 65 ns on a 2 GHz Core 2 Duo -- my old HP laptop.) Yes, you still need to carefully check the operations, but the physical effort required to actually implement it is relatively small. I've threaded about a dozen operations in our code so far, delivering massive performance improvements to the customers, and so far only one minor threading bug turned up (a race condition due to a missing critical section).

(Luckily a large number of operations are very functional in nature -- they may read a lot of data that doesn't get modified, but they either write to well-controlled shared data structures that are easy to protect or the output is well-partitioned and can be coalesced later. We don't modify global variables as a rule so generally the only side effect is a progress bar that we update from each thread in a thread-safe way so users have something to look at.)

You have to be careful, yes -- just like C++ programming in general -- but it's not that hard, and certainly a lot less error-prone and expensive than a major rewrite to make the code and data structures "multiprocessing friendly". And it's fast.