LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Library function error (return value == -1 [oxffffffff]) Bad file handle

We are using LabWindows CVI Version 5 & 5.5.  Interminitly we get the above error when opening, writing or closing a file.  The program is a threaded program and the files the threads are accessing are not the same.  In searching the archives it has been mentioned that in some instances, the same file handle may be used for other threads, thus, you open one file and just after the open, another thread closes the file before the first file has a chance to write to it.  This would then give the above error.  Sometimes it takes 2 minutes to generate this error, other times it takes a couple days.  We do not get this error if we run only 1 thread.  We get into trouble when we run multiple threads.  Any help or insite to this problem would be greatly appreciated.
 
Thanks,
TOM B
0 Kudos
Message 1 of 5
(5,903 Views)
Hi, Tom.

It definitely sounds like some sort of thread-related race condition is occurring. A good method for debugging this type of problem is to create an integer for each file and set it to zero. Then you can increment it every time the file is opened and decrement it every time the file is closed. Then you can easily test the value of that integer periodically; if it's any value besides 0 or 1, you know that two different threads have accessed the file at the same time. By using frequent checks in your code, you can determine where and under what circumstances this behavior occurs.

Let me know how it goes! Good luck.
Sarah K.
Search PME
National Instruments
0 Kudos
Message 2 of 5
(5,877 Views)
We know we are having problems and was asked to create a little program that only works with files.  I have duplicated the problem but can not resolve it.  Here is what I am doing:
 
I remove any files that might exist with the same name
Create the file entitled Unit (i).txt (example Unit1.txt, Unit2.txt..........)
Create a unique small text message and write it to the file
Close the file
Open the file
Read the file
Compare the text message in the file to the one I ogrinally created
Close the file
 
If I do this with a single thread, it works no problem.  If I increase the number of threads to 32, it fails almost all the time.  We tried an experiment writing the file name, file handle and some other information using printf and it helped, but still failed (mostly because it causes the program to run slower as it is trying to write to the screen).  Odd thing we noticed, the file handle number is often the same for all threads, or it is different, but shared with other threads.  Any way I could send you a zip of our program so maybe you can tell us where we have gone wrong?
 
Thanks,
TOM B
0 Kudos
Message 3 of 5
(5,838 Views)

Hi Tom.

You can avoid the problems you are seeing by handling all of your disk writes in a single, dedicated thread.

I would either set up multiple thread-safe queues (one per "writer" thread, using CmtNewTSQ() etc. from the Utility library), or use PostDeferredCallToThread() in each of the "writer" threads. Either method will free your threads from time-consuming disk I/O operations.

If you must perform disk access from multiple threads, use a thread lock or similar device to serialise write operations.

Regards,
Colin.

 

0 Kudos
Message 4 of 5
(5,835 Views)

From the input I have received, it appears we can not do multiple writes to disk in a threaded environment in the threads themselves.  It is not just writing to disk, it is also reading, accessing and manipulating several files per thread.  It appears the only option to this it to create a critical section per write/read/create instance.  It really is not that hard, just takes away some of the benefit of running threads in the first place.  Any other suggestion, fire away.

Thanks again,

TOM B

0 Kudos
Message 5 of 5
(5,798 Views)