lp0 on fire
Sep. 25th, 2008 12:03 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ljpliceaseI 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.
