The antisocial software that I am trying to rehabilitate has one of those threading difficulties--and it took a while to figure it out. The user interface has a Save button; you click it, and it both saves data to the database, and then checks to see if the offender's home address is the same as any other offender in the system. If there are other matches, it throws up a popup window that displays the other offenders at the same home address.
Of course, that popup window is done through a separate thread--but the abusive software parent responsible for this piece of code did not think about the fact that both threads were sharing the same database connection object. If the retrieve matching addresses thread finished its SQL operation before the save thread started, everything worked just fine. But as the number of matching addresses increased much above ten, the odds were excellent that the retrieve thread would still be retrieving data when the save thread closed the connection.
The database connection is now closed: but the retrieve thread is still retrieving data. The results were highly unpredictable, with at least four different error messages that might appear, depending on timing. Only occasionally did the SQL Exception come up "Connection already closed" which was the tipoff that something was not right.
Sad to say, there are more than a thousand popup windows in this system, and trying to figure out which of those are this sort of multithreaded monstrosity will keep me busy for decades. Unlike Sisyphus, at least I get to retire in a few years.