cmultithreadingoptimizationmingw

I turned on compiler optimization and my multithreaded C program imploded aggressively, any articles I can read on this?


I'm using MinGW, which is gcc for Windows. My program involves multiple windows, two different main threads, and several worker threads in a thread pool for overlapped network I/O.

It works perfectly fine without compiler optimization.

A) Is compiler optimization even necessary? My program's already very fast. Is it at all likely that it will provide a significant improvement?

B) Are there any articles on how to properly build a multthreaded program so compiler optimization can do its job?


Solution

  • 99.9% of all household failures in one optimization mode and not another are due to serious bugs. Multithreading races etc. are very sensitive to code performance. An instruction reorder or loop shortcut can turn a test pass into a debugging nightmare.

    I'm assuming that the server runs up OK and detonates under load in aparrently different places, so making conventional debugging useless?

    You are going to have to rely on logging and changing the test conditions to narrow down the point of ignition. My guess is this is going to be a Heisenbug that mutates with changes to the code, optimization, options, load profile, buffer sizes etc.

    Not fixing the problem is not a good plan since it wil just show up in another form on next years boxes with more cores etc. Even with optimization off, it's still there, lurking, waiting for the opportunity to strike.

    I hope I'm providing some comfort.

    Seriously - log everything you can with a good logger - one that queues up the logs so as to keep disk latency out of the main app. Change things around to try and make the bug mutate and perhaps show up in the non-optimized build too. Write down, (type in), absolutely everything that you do amd what happens after any change, good or bad. Making the bug worse is actually better than making its symptoms go away, (without knowing exactly why). Try the server on various hardware configs, if you can.

    Eventually, you will find the bug!

    You have one thing going for you - it seems that you can reliably reproduce the problem. That, in itself, is a massive plus.

    Forgot to ask - apart from the nuclear explosive metaphor, what is the main symptom? Is it AV'ing/segfaulting all over the place, or is it locked or livelocked up?