The Twilight Report

I wonder why they bother teaching concurrency in computer science. There is this funny problem they teach you, involving n philosophers and n forks and a big pot of spaghetti which, if you solve it wrongly, could cause n philosophers to die of starvation. It's a well understood problem, and there are tones of tools to address it properly, most of which have been around for decades on every platform imaginable.

When I was working on parallel abstraction and timing at The Company, I went to a lot of effort to make sure that it worked concurrently. This put me in conflict with people who were too lazy to make sure their code worked properly in parallel. I even tried to make tools to make it easier for them to make code parallel safe, but no, that was too much effort, even though it mostly amounted to using a different class with the exact same interface.

In my current job at s-mart we use a locking mechanism which has an inherent race condition. Which means if something goes wrong it might corrupt data. Admittedly, the odds of that are quite low, but I don't understand why we don't use proper locking (ie. flock), which isn't conceptually any more complicated than the "simple"^[1] locking scheme that we use. In my last job at Company 2, we had a similar locking scheme, but it was hand coded, they didn't even bother to re-use the "simple" locking scheme provided by perl for systems that don't have flock^[2].

I found this list of the The Thirteen Greatest Error Messages of All Time. I can't help but wonder if a bit more time thinking about concurrency could have kept some of these from happening often enough to make the list.

1. read as: broken
2. and even Windows perl has adequate flock emulation now, so why is anyone using this again?