Concurrency problems in real life.

Applications of Computer Science problems/topics in real life are always amusing.  They really hammer home the need for good discipline in software development, but work slow enough that the software engineer can easily identify the problem and a solution to negate it in the future.  This week I was lucky enough to be on the receiving end of the consequences of a concurrency problem/timing attack caused by poor system design.

I recently moved into a new apartment and had my utilities transfered over.  My move-in date was fairly close to the previous occupants move-out date – I believe there was a week between the two events. They were subscribers to Time Warner cable, as am I. This led to a minor but harmless locking issue, as I could not schedule my service to transfer to the new apartment until they had scheduled theirs to be disconnected. I like to get such things taken care of early, so this was a small pain, but eventually the lock was released and my install was scheduled.

On the Monday after I moved in, the cable fellow came to my door, and delivered to me sweet, sweet internet. Previous to this the cable worked (extended basic cable, to be specific), which I thought was odd, but I dismissed it. I carry on with my life, no longer relying on unsecured wireless access to communicate with the outside world.

On the Friday after I moved in, at around 11:30 AM,  my  connection to the world was severed abruptly.   Additionally, though it was not the same heartbreaking loss, I no longer had cable TV.  I got on the horn with Time Warner and requested that a tech be sent out again as soon as possible to remedy this. After some brow beating, the customer service representative “scheduled” a tech to come out the following morning between 8 and 11. Finding this acceptable, I went on with my life.

The next morning, no tech shows up and I have a lovely four hours sitting in my living room in my PJs getting stood up by my cable company. Time Warner’s customer service line rings again, and I have a long, drawn out conversation with another CSR about the situation. I was informed my appointment was canceled and that I have a new one for 1 to 4 PM the following Tuesday.  After I finished having blood shoot out of my eyes and was transferred to Customer Retention Department (while I was very serious about wanting to cancel my account, the CSR I was talking to was not the most skilled worker bee they have and Retention people are much more effective), investigation revealed that the CSR previous scheduled my appointment for Tuesday and then backdated an “Incomplete Install” ticket to get the Saturday appointment. Dispatch was less than pleased, and just disregarded the order without notifying me.  The Retentions fellow was helpful (though a liar), and promised to try and expedite the tech visit while giving me a free month of service. Whatever. My appointment still happened on Tuesday, at around 1 PM, and I had to miss some work for it. I’m still angry, but I have internet now and this isn’t really the focus of the story.

While the Tech was here removing the filter that had suddenly found itself on my cable line, I asked him about the situation. He said that it is very likely there was a disconnect order from the previous subscriber that was fulfilled a little late, and that problems like this are very common in multiple occupancy residences such as an apartment complex.

It seems to me that a small change in their operating procedure can easily eliminate this problem entirely. They obviously have ability to ‘lock down’ changes to service to a unit based upon the existence of a previous subscriber. The issue here is that they lock on the wrong part of the transaction (or at least incompletely acquire the lock for the transaction) for adding tasks to their scheduling mechanism.  The lock allows only an authorized subscriber to schedule a task for a unit, but the lock is not rechecked for when the task runs at a later time, and can run at a later time when the subscriber no longer holds the lock. This means you can craft a very slow timing attack against another Time Warner subscriber after you move out and disconnect their service to annoy them for a good four days, since local monopoly cable companies don’t really give a crap when a customer has a complete loss of service.