FSUIPC 3.93 + FS2004, Getting data error in thread

[codeking]

Hi

I have strange problem with getting data from FSUIPC in C#.

My situation:

- application with two threads

- first thread is reading data with 50ms interval

- second thread is writing data when needed

- each thread is using its own fsuipc class object from SDK (UIPC_SDK_CSHARP Revision 1.13)

Sometimes, after writing data (sending control (offset 0x3110) COM_RADIO_FRACT_INC), FSUIPC_Get(...) method in reading thread returns false (after debugging it, I've found, that it returns false because data I want to read is not ready (IPCdr[Token] == false).

This problem has really bothered me, so I moved to test example (in C#) which is added to SDK. I've added button which writes to FSUIPC (the same offset as above) but using other fsuipc class object then the rest of application. Started application, started loop which is reading data and pressed that button many times - zero errors (added some flags to see it). But this example application is not using extra thread. Reading loop is placed in main thread with call to Application.DoEvents() function. So I've added thread and reading loop in it. Again test and - voile - errors in getting data. So, it seems that reading data from FSUIPC should be placed in main thread of Windows application, not in extra thread specified to doing it. Am I right ? If so, I will try to repair my app, otherwise what can be wrong ?

PS. Sorry for my English.

[Pete Dowson]

I have strange problem with getting data from FSUIPC in C#.

I hope someone else reading this can help - C# is outside my sphere of knowledge, and, I think, being a completely managed language, is subject to a lot of peculiarities when trying to address something with a native mode C/C++ interface. However, I do have one observation:

- application with two threads

- first thread is reading data with 50ms interval

- second thread is writing data when needed

- each thread is using its own fsuipc class object from SDK (UIPC_SDK_CSHARP Revision 1.13)

Even though each thread supposedly uses its own connection to FSUIPC, unless the code in the "class object" you are using does something very different to make its "atom" identifier different, both threads will actually be using the same memory-mapped object in order to talk to FSUIPC. The memory-mapped object is normally identified by an atom id obtained using a string name generated using a fixed portion and a portion generated from the PROCESS ID -- which will be the same for both threads.

Since the code for generating this string ID is actually part of your program, it can of course be changed -- possibly by also including the Thread ID -- but maybe this has not been done?

If both threads are sharing the same memory mapped file area for transfer of data to and from FSUIPC, then without some sort of lockout semaphore arrangements you are going to get one thread corrupting the other's data sooner or later.

Regards

Pete

[codeking]

Thanks for help.

Even though each thread supposedly uses its own connection to FSUIPC, unless the code in the "class object" you are using does something very different to make its "atom" identifier different, both threads will actually be using the same memory-mapped object in order to talk to FSUIPC. The memory-mapped object is normally identified by an atom id obtained using a string name generated using a fixed portion and a portion generated from the PROCESS ID -- which will be the same for both threads.

Since the code for generating this string ID is actually part of your program, it can of course be changed -- possibly by also including the Thread ID -- but maybe this has not been done?

Yes, I've spend some after posting, on finding solution and I found one. Adding some thread synchronization mechanism solved the problem. But after Your post, it turned out that some code constructing name for ATOM (in fsuipc.cs) is getting Process ID as a unique value, so changing it for thread id solved the problem and it's better because threads synchronization can take some time (I know, a little in these days) and resources. So my app works as I wanted to.

Again, thanks for help.

PS. Maybe little change in C# SDK should be change in case of problems like mine :)

Best regards

codeking