5
phorkyas
35d

So to give you a feel for what evil, clusterfuck code it was in: this projects largest part was coded by a maniac, witty physicist confined in the factory for a month, intended as a 'provisional' solution of course it ran for years. The style was like C with a bit of classes.. and a big chunk of shared memory as a global mud of storage, communication and catastrophe. Optimistic or no locking of the memory between process barriers, arrays with self implemented boundary checks that would give you the zeroth element on failure and write an error log of which there were often dozens in the log. But if that sounds terrifying already, it is only baseline uneasyness which was largely surpassed by the shear mass of code, special units, undocumented madness. And I had like three month to write a simulator of the physical factory and sensors to feed that behemoth with the 'right' inputs. Still I don't know how I stood it through, but I resigned little time afterwards.

Well, lastly to the bug: there was some central map in that shared memory that hold like view of the central customer data. And somehow - maybe not that surprisingly giving the surrounding codebase - it sometimes got corrupted. Once in a month or two times a day. Tried to put in logging, more checks - but never really could pinpoint the problem... Till today I still get the haunting feeling of a luring memory corruption beneath my feet, if I get closer to the metal core of pure C.

Comments
  • 2
    Yeah concurrent memory access in C can be quite a bitch. I usually follow this standard plan:

    1) Decouple. Things that aren't shared are fast and easy to get right.
    2) Lock. Slap a mutex / critical section around the access.
    3) If 2) becomes a proven bottleneck, back to 1). If that is already exhausted, only then it's time for deep shit like atomic access and memory barriers, but that should never be the start.
Your Job Suck?
Get a Better Job
Add Comment