LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

InstallWinMsgCallback GPF with CVI 8.5

I'm glad this fixed your problem. However, after I posted that version of toolbox.c, we made another incremental change, in order to tighten up the multithread protection. The previous version could still incur a crash, in some less common situations. I'm attaching the latest version here. You might ad want to use this one instead, just in case.

If you see any crash at all using this latest version of toolbox.c, please do post an update here, since we do not expect any errors at this time.

And yes, we do plan on rolling this change into the next major CVI release.

Thanks for your help!

Luis

0 Kudos
Message 11 of 24
(1,594 Views)
Luis,

I haven't had huge amounts of time to throughly test the new files, but on more than a handfull of occasions my program is hanging on "sendmessage" using the second file you attached.   I set a BP in the message handler of the target thread (the main thread in this case) and it never hit... since sendmessage sits and waits for the message to be processed, it hangs there.  Using the first file you attached I haven't had the hang as of yet.

Also for what its worth, the second file, makes my release executable about 50k less in size.
0 Kudos
Message 12 of 24
(1,569 Views)
Actually, using SendMessage to communicate between two threads, wherein each thread is using the same library, is inherently problematic, and can lead to deadlocks. The problem is that while one thread is holding on to the library lock, it might send a message to the other thread, and if that thread then calls the same library, the library can't acquire the same lock, since the lock is being held by the first thread. But the first thread will never release the lock, since it too is waiting for the second thread to reply to the SendMessage call. So the threads are waiting on each other, and you have a hang.

It's likely that this hang did not manifest itself in the previous version of the code, since that code did not include any thread-protection locking. So there were no deadlocks, but you had memory corruption instead. Now, the memory corruption should no longer occur, but you have the potential for deadlocks, if the threads interact in a dangerous way. And calling SendMessage would be considered interacting in a dangerous way.

Have you considered using PostMessage instead? Using PostMessage, the sending thread doesn't have to wait for the receiving thread, so the potential for deadlocks is greatly reduced.

Luis
0 Kudos
Message 13 of 24
(1,554 Views)
I had actually considered post message, which I do in most cases.  In the case of sendmesage, (and with my limited understanding of messagning) I'm actually sending a pointer to a data structure in the LPARAM parameter... I used sendmessage because I knew it waited and then way my data was gurenteed to not change while the other thread was using it.

Would I have to use some kinda of global with a thread lock to get around this, or do you have some other ideas?
0 Kudos
Message 14 of 24
(1,550 Views)
If you are sharing data between the two threads, it's definitely a good idea to protect this data with a lock, especially if it's possible for both threads to modify the data. Even if only one thread modifies the data and the other thread reads it, it might be a good idea to protect it with a lock, in case bad timing might result in the second thread reading bad data.
 
In addition, it sounds as if you are relying on the thread that receives the data to be read it before the first thread makes additional modifications to it. This is a separate synchronization issue, which will not be handled automatically by locking the data. In this case, any kind of additional synchronization you do (for example, having the first thread wait, just before modifying the data, until the second thread signals that it has read it) runs the risk of creating deadlocks -- since, effectively, that would be equivalent to doing a SendMessage.
I think a better solution would be for you to make a copy of the data, and post the copy to the reading thread. That way, you can be sure that the reading thread reads the exact version of the data that you sent it.
 
Luis
0 Kudos
Message 15 of 24
(1,529 Views)
Luis,

I'm using the latest file you send and just have a general question before I get into the specifics of what I beleive is a deadlock issue I'm having.

In a message listener function, is it legal to use functions such as setctrlattribute?  It was working find before, but now with the multithreading changes I have some issues. 

Hard to explain, but here is hopefully the short version:  Thread 1 is processing a message (stack call is Thread1->MsgHandlerWndProc->Thread1MsgProcessor) and when I am able to break in with the debugger, the highlighted line is on a setctrlattribute.  The main thread apears to also be in MsgHandlerWndProc (main->MsgHandlerWndProc->GetPointerToMsgCBHandlers) trying to process some windows message from what I can tell (Message = 132 in the call), but it appears that since Thread 1 is also in there with a lock on "MsgCBHandlers" noone is going anywhere.  Am I on the right track here?  Let me know if you need more info, I can take some screen shots of all the variables if need be.

Thanks.

0 Kudos
Message 16 of 24
(1,428 Views)
In theory, there is no problem with calling SetCtrlAttribute from either thread.
 
Thread synchronization issues can be pretty hard to wrap one's head around, so just based on your description it would be hard for me to speculate. What would really help would be if I could run your project here and reproduce the problem. I could then break into it with the debugger, and with the advantage of being able to see what's going on inside SetCtrlAttribute I should be able to see what is causing the deadlock.
 
Would you be able to zip up your project, and attach it here? Or if you'd rather not post it publicly, I could give you an ftp site that you could submit it to. If your application depends on some specific hardware, is it possible to modify it so that it can get simulated data, or somesuch?
 
Luis
0 Kudos
Message 17 of 24
(1,408 Views)
I'm trying to take out specific hardware calls and such now.  I would prefer not to post it publicly, so what is your private ftp site I can upload it to?  You can email me if you don't want to post it on here as well.  While there's no official NDA and I am trying to take as much out as possible while still being able to reproduce the issue, I assume everything would still be kept confidential. 🙂

Thanks for your help.

0 Kudos
Message 18 of 24
(1,400 Views)
You can submit it here:
 
 
Just drop a note here when you submit it, so that I know to look for it. And yes, it'll definitely be confidential 🙂
 
Thanks,
Luis
0 Kudos
Message 19 of 24
(1,395 Views)
Ok Luis,

Hopefully I didn't rip out too much stuff, but it still locks consistently on my machine.  The file is gtoph_ThreadIssue.zip.  There are two main windows that initially popup, you'll want to be in the "primary" one and then use the upper left most child window.... I relabeled the buttons you need to press to get to the problem consistently.  If you have any questions just let me know.

Thanks again for your help.


0 Kudos
Message 20 of 24
(1,391 Views)