visa async read thread switch

[Phil R]

Posted this to the Visa board, but got no responses so trying here.

I'm accessing bluetooth Serial Port devices over TCP/IP using Visa and MFC with Measurement Studio. Each device has its own dialog and its own thread and each device is reading async. At the end of my event handler for the IOComplete event I perform another async read. I notice that if I read more than around 550 bytes the async handler thread releases control and the message pump for the dialog gets in. If I read less than around 550 bytes the handler thread never releases control and the message pump never gets back in - the event handler just gets called immediately. Is there a parameter somewhere I should be setting to fix this. For one device I want to read 10 samples at a time which relates to 0.1 sec of captured data. Each packet is 22 bytes which makes my read 220 bytes.  Thanks

[Mr.F]

Hi Phil,

What do you mean by message pump? Can you post your code and maybe try and explain what’s going on a little bit more clearly?

[Phil R]

In windows every dialog has a message pump. Google "message pump" for details. It allows the user to interact with the dialog. If my code never relinquishes control then the message pump never gets control so I can't interact with the dialog.

I'm doing standard async read processing - 

Install event handler

do an async read

in the event handler, do my processing and then

do another async read

I do the async read like this :

m_Session->Read((ViBuf)msg_block1, (m_iPacketSize * m_iPacketsPerBlock), myJobId);

and at the end of my event handler for this I have do another async read just the same:

    m_Session->Read((ViBuf)msg_block1, m_iPacketSize * m_iPacketsPerBlock, myJobId);

    return VisaSuccess;

This should end the event handler function and return to the message pump, but it seems that it doesn't end the function, rather it just immediatelg calls it again. Thus there's no return and the message pump doesn't get back in.

I also tried forcing a thread switch with ::SwitchToThread(); but that doesn't seem to help.

As I said this behaviour only happens when I get down to around 550 bytes in the read.

Thanks

[Mr.F]

Hi Phil,

This sounds like it’s pretty repeatable. Can you post a spy capture of both cases? (Working and not?) I’d like to check the VISA status to see if anything is different there.

[Phil R]

Here you go. I started up the app and let it run a bit in each case - hence the different file sizes. In the "Small Packets" file one of the devices has a read size under 550 and the other has the size over 550. In the "large packets" both devices are over 550. I did find a workround for my issue. Instead of sending a message to the thread I set a variable in the thread and check that constantly in the thread.

[Mariana123]

Thanks for discussing about visa async read thread switch.

Thanks & Regards

Mariana

Data recovery

[Phil R]

Happy to discuss. Looking for solution still though.

[Mr.F]

Hi Phil,

Your previous post indicated that you had found a work around. Does that not work for your application? I’m afraid I don’t have the hardware you have; can you reproduce this with serial communication? Can you post your code?

[Phil R]

I found a work around, not a solution. There's not much more code to post. Right now I'm on a deadline so I don't have time to try this with serial comm. I'll try to get to it after next week. It may well be a windows timing issue in that when I get down to doing a read and the data is already there - as it might be with very small packets - then the NI code just doesn't relinquish code. Would you happen to know if the NI code does any forced thread switches to let other threads get in (::SwitchToThread() calls)?

[Song_D]

Phil,

What exactly does the 550 read size you mentioned mean? From the Spy logs, it seems like you are reading 700 bytes in one thread and 1100 in the other. So I wonder if 550 meant the packet size the device is sending.

Also, just to clarify the issue, you are basically saying the thread reading 1100 bytes per read is starved if the packet size is smaller than 550, correct? I don't think we do any explicit thread switching in our code, but I need to double check.