We have a base class used widely in a homegrown OPF that was retrofitted to make it thread safe. Unfortunately the conversion was done incrementally by test-and-fix, rather than redesign or code review. So over time as we use more multithreaded code more intensely we're running into new places where the code doesn't cope with threads.

We have a base class used widely in a homegrown OPF that was retrofitted to make it thread safe. Unfortunately the conversion was done incrementally by test-and-fix, rather than redesign or code review. So over time as we use more multithreaded code more intensely we're running into new places where the code doesn't cope with threads.

Todays discovery was that a couple of TList instances that were assumed to be add-only actually have remove operations performed. Which has the expected disastrous effects on code that iterates, especially code that iterates slowly.

foreground thread
  FillList;
  StartBackgroundThread;
  DisplayList;
  ... let user edit the list

background thread:
  for i := 0 to List.Count do
    GatherStatsFromDatabase(List[i]);

Users don't delete stuff very often, and especially it is hard to delete stuff while the background thread is still running... at least on a fast developer machine running against a local database. On a heavily loaded Citrix server against an overloaded database server all sorts of things can happen. Testing in a VM with limited memory and 7z compressing a file seems to have the desired effect. Although could I mention again that VirtualBox is overpriced junk.

Replace TList with TThreadList and things run a little slower (~1%) but so far, cross fingers, not so many list index out of bounds errors and access violations.