Problems with threads

[OZI]

Hi

we are using CVI 2012 and we use several threads in our application. Normally our application is running in a good way but from time to time we have a problem that a thread make our main application run slower. That means, for example, we have one thread which saves a picture to the hard disc. This is normally running fine but from time to time we see that the application nearly stops for a moment.

This is not normal. Normally a thread runs independent from the main application

To see when a thread is running and how long it needs we use a time function. That means, we the thread starts we get the current time and also we it stopps we get the time.

Start = Timer();

End = Timer();

Diff = End - Start;

Could this be a problem?

thanks

Oliver

[Johannes_T]

Hello OZI!

1. Are you using any synchronization resources (mutexes/locks/waits) between your threads, that could possible contribute to this hang?
2. How are you performing the operation that you are claiming being responsible for the hang? Which functions are you calling to save the file to disk?

Thank you!

[OZI]

Hello Jay_Tee

we are using locks to save the threads against each others. It looks like this:

//
CmtGetLock(ThreadLock);

code

//
CmtReleaseLock(ThreadLock);

What do you mean with: How are you performing the operation...

Saving pictures is only one thing we do in the threads. Also the other threads are making problems from time to time. For saving the pictures we use:   

//
SaveBitmapToPNGFile(Picture->Handle, Picture->FileName);

Thanks

Oliver

[Johannes_T]

Hello Oliver!

The CVI libraries are multithread-safe, so you are perfectly entitled to call such library functions from other threads.

So theoretically, the problem might be one thread taking too long (e.g. the thread respondible for saving the image to disk), because of slow disk access, and blocking the other threads while these are waiting for a resource.

I think it's unlikely that the problem lies in the retrieval of the timestamps.

How are you determining that your application is halted for a period of time. Does the UI become unresponsive? Perhaps this is due to the fact that a UI callback (from the main thread) is waiting for some resources blocked by the other thread.

There is a thread-related discussion about how another user had had troubleshooted problems in his code at: http://forums.ni.com/t5/LabWindows-CVI/Multithreading-and-partitioned-shared-memory/td-p/2707287 Maybe this could be of some help.

[OZI]

Hello Johannes,

to know when our threads are running we log the time at the beginning and at the end of the thread.

At the beginning we get the time

Start = Timer();

...Code...

End = Timer();

So we know when the thread is running. In our application we have a window were all functions and threads are listed and with bars we display when they are running. So we can see approximately the timing of our application. From time to time we see that a thread is taking to long and slows down other functions. We can not explain this because normally a thread can not slow down the main application. There is the main problem. We put some functions in threads to keep the main application running in the highest speed and then the thread is slowing down the main app.

but now I came to an other idea because of your answer. What happens when there are two threads of the same priority want to run in the same time?

best regards

Oliver

[OZI]

One question:

What happens if there are two threads with the same priority running at the same time?

- Do they interrupt each other in a time slice?

- Does one thread have to wait until the other is finished?

greetings

Oliver

[Johannes_T]

Normally, at a system level, threads with equal priority are scheduled in a round-robin policy, i.e. time-sliced: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100.aspx

However, have you tried to log the actions of your threads as the system runs? For instance, you can log actions/operations of each thread, so that you determine the state of each thread and what they were doing when the hand occurs. This helps narrow down on the exact cause of the problem, and can reveal the function or resource that is being responsible for the delay.

[menchar]

This may more likely be a Windows / NTFS issue.  When writing large files to disk, I've noticed that the OS (I use Win7) is making threading / scheduling decisions for its own reasons that cause an application (if not the entire system) to slow down or appear to lock up.  This is true with apps created entirely with Visual Studio, nothing to do with CVI per se.

It could be that even if you were to do the file write on a separate thread with low priority it would still slow things way down, since a Windows OS will unilaterally change thread priority if it thinks there's a good reason.  In a desktop OS like windows with typically hundreds of threads concurrently running, you can get priority inversion where an unrelated thread winds up stealing all the CPU time by getting in between your application's high and low priority threads.  To avoid this, windows will randomly boost thread priorities from time to time, but in the case of large file writes I don't think it's a random boost - the OS does it very purposefully, maybe to keep a thrashing disk operation with a large file from hosing up all the other threads trying to use the disk.

If the file write were to be segmented somehow it might help, rather than try to write the large file in one write at low priority (but then have the OS boost the disk write thread's priority to get the write completed and lock things up) if you were to write it in several pieces there would be more opportunities for the OS to schedule threads more predictably.

We've gone to solid state disk drives to avoid these issues for very large, multi-gigabyte files.