Michael S (already5chosen@yahoo.com) on 8/18/09 wrote:
---------------------------

>If the app is multiplatform it's another matter. Although by now standard compliance
>of popular C++ compilers is MUCH better than it used to be just 5-6 years ago so I wouldn't expect correctness problems.

Maybe. I'm a bit of a Luddite on much of this stuff: I'm
not interested in using features until they've been around
for a while (and from what you're saying, while templates
and STL were kinda sorta around in 1995, it was a bit of a
crapshoot until around 2004 ...)

>BTW, did you test performance effect of trie-based sort on >all relevant platforms?

No, I didn't reach that point.

>>Actually, I spent a nasty few weeks back in Jan and Feb
>>tracking down an ugly problem where some apps using our
>>own memory allocator were seeing weird behavior, while
>>others were fine. And it turned out to happen because
>>those apps had multiple threads, and even though the
>>multiple threads didn't do memory allocation, the mere
>>presence of multiple threads causes the glibc malloc()
>>to have different behavior, using mmap() for some
>>allocations in a way which you can't control.
>
>Doesn't it mean that your original design was relying on >undefined behavior?

Yes it was. Not a good idea in general. But we're up
against the wall in terms of trying to build big data
structures that need to fit in physical DRAM to go fast
enough, so we play some tricks with squeezing virtual
addresses into less than 64 bits.

Playing it safe is good. But sometimes you can't get what
you need without breaking a few rules.

Anyhow, the consequence for our app was that introducing
even a minimal use of threads actually made things
break. For apps which are less sensitive to memory
address ranges, what you might see is that your program
still runs, but behaves a little differently ... either
way it's awkward.

>I am sure that on Windows it wouldn't cause that sort of side effects. As long
>as you know what you are doing you can use multiple threads in Windows application
>without switching to thread-aware variant of RTL.

We're all Linux: managed to avoid porting to Windows,
thank heavens. And personally, I wouldn't feel at all
confident about running a 100GB process for 20 hours on
any Windows machine. Though maybe that's unfair, I haven't
really used Windows since around 2000 and it's perhaps
less flaky than it used to be.

>Used like panacea - yes. But it doesn't mean that there are no cases where Windows
>treads/pthreads (is it what you mean by "lightweight threads"?) are easy to use and cause no problems at all.

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.