Is there a way to make the application work as single-threaded?

Question

We have an old project that we support, and there is a problem that arises, most likely due to multithreading. The original developer “fixed” it by running Thread.sleep before executing the problem section. The workaround works, but since the section is inside the loop, Thread.sleep adds a few minutes to the time it takes to complete the section.

Last month we experimented with lower sleep values, but we want to find the root cause. During our research, we did lock on private objects, wherever we wanted it. We looked for everything that could generate additional flows - we did not find any. There is no Thread.start and no use of ThreadPool. What bothers us is that during debugging we find our main thread in the middle of about 8 other threads that we don’t know who generated them. These are background threads, so at first I thought I had threadpool, but since I did not mention this in the code.

This is .net 2.0, so there is no Async s. This is just part of a larger application, therefore it is a Windows service, but we run it as CMD to easily debug it. The main application is a Windows form application for desktop computers. It also uses COM + components if this is any help.

I tried [STA] instead of [MTA] . Also lock as above. MemoryBarrier .

We are still facing a problem.

The problem is mostly distorted by datasets and zeros in objects where they should not be. This happens approximately once every 25-100 iterations, so playback is not direct, but we developed a test specifically for this problem to try to reproduce it.

Everything that indicates the direction of flow problems.

Back to the original question - Who could have spawned these additional threads and how do we prevent the creation of these threads?

Please note that threads marked in red are background threads, and as far as we can not notice them in the code.

The alleged stream in the screenshot actively modifies the cols in the dataset . The problem is that the methods that call the SetColValueOnRow function executed by the thread are typical and do not use any thread.

The processor affinity for this application is set to 1 Core [part of the original workflow]

thanks

Edit: The database is oracle 12c, but the problems that we encounter occur before writing to the database. They usually happen in DataSets, where an entire record or several of its columns can be erased once every several testing iterations.

Answer 1

I think you need to find out why Thread.sleep works. It doesn't look like the code itself spawns additional threads, but you need to go through the entire code base to find this, including COM + components.

So, the first thing I would like to do is run the program in debugging and just press the F10 key to enter the program. Then open the thread debugging window and see if you see about as many threads as indicated in your question. If you do this, then these are just threads from the thread pool, and your problem is probably not related to multiple threads.

If you do not see the same number of threads, try setting a breakpoint at different stages of the program and see if you can find where these threads are created. When you discover where they are created, you can try adding some lock at this point. But your problem still cannot be caused by multiple threads that distort memory. You should investigate until you are sure that the problem is with multiple threads or something else.

I suspect that the problem may be related to one or more COM + components, or maybe the code calls some long-running database stored procedure. In any case, I suspect the reason Thread.sleep works because it gives the suspect component enough time to complete its work before proceeding with the next operation.

If this theory is true, then it assumes that there is some relationship between operations, and when Thread.Sleep gets big enough to complete the operation, there are no problems with the interaction. This also suggests that perhaps one of the components of COM + does some things asynchronously. The solution could be to use locks or critical sections inside COM + code. Another idea is to reverse engineer the section of code that causes the problem to resolve multiple operations at the same time.

Thus, the problem you are facing may not be due to the multiple threads in the C # code that you are looking at, but may be due to the long-term work, which sometimes fails if enough time is not provided for completion, before starting the next operation. This may or may not be due to multiple threads in C # code.