Multi-thread safety in FSUIPC

[hbien]

First - a great thank you to Mr. Dowson - you have made it so much easier to communicate with MSFS.

Second, my question(s):

1. Is FSUIPC multi-thread safe? That is, can I stack several FSUIPC_Read/Write() and a FSUIPC_Process() in one thread, while concurrently in another thread of the same process perform FSUIPC_Read/Write's() and FSUIPC_Process()? I'm writing a hardware emulator to interface with MSFS using FSUIPC, and it currently has several threads, one of which performs about 10 or so reads followed by a process, and the other doing about 5 writes followed by another process. These threads are run concurrently and asynchronously, so I cannot guarantee that the Process() in one thread will be completed before a Process() in the other thread.

2. Where might I find the error codes as reported from FSUIPC's DWORD result? I'm looking all over the docs but cannot seem to find them. Specifically, once in a rare while I get error code 13 in my loop - what is that?

3. As another user pointed out, I initially wanted to bypass FSUIPC and hookup directly with MSFS, but finding no documentation on how to write MSFS modules, I gave up and went with FSUIPC (its great, but it incurs its own over-head which I'd rather avoid). I see that there are no documentation on writing your own module, is there a reason why? I find it surprising that you had to hack into MSFS to get FSUIPC working. You'd think the least microsoft could've done with all the addon's that rely on MSFS FSUIPC would be to supply you or anyone else with a module SDK.

Anyway, thanks for a great product (the overhead, it turned out, is negligible so far and the programs are running fine). Looking forward to your response.

Sincerely,

Harold Bien

[Pete Dowson]

Is FSUIPC multi-thread safe? That is, can I stack several FSUIPC_Read/Write() and a FSUIPC_Process() in one thread, while concurrently in another thread of the same process perform FSUIPC_Read/Write's() and FSUIPC_Process()?

Since the code handling all that stuff is in your own program, it depends how you program it. If you are just using the static C library I provide in the SDK then your main problem will be to avoid multiple interleaved access to the pointers to your memory-mapped file area, creating a corrupt data block for transfer by FSUIPC_Process.

The only place FSUIPC comes into this is when being called by the Windows Messaging system via the SendMessageTimeout call. If you have one thread changing the same memory-mapped file data area that you just passed to FSUIPC for processing, obviously that will get corrupted.

You either need to implement semaphore lockouts around the memory-mapped data and pointer access, or open a separate memory-mapped file for each case (i.e. effectively a separate FSUIPC_Open). However, this latter solution creates another problem -- if you always interface to user-registered copies of FSUIPC there is no problem, but there is no way for FSUIPC to grant keyed access instigated from any thread other than the main process thread. (You could probably get around that by creating all the Open's (i.e. memory-mapped files) you need, one for each thread, in the main thread, and take care to use the right one in the right place. But it starts to get very messy).

Anyway, since the complete source of everything about the interface to FSUIPC is included in the SDK, I am sure that you can devise a more elegant solution -- probably by funnelling access through the main thread only, or by maintaining separate data areas and swapping them into a single memory-mapped area under semaphore lockout control.

Where might I find the error codes as reported from FSUIPC's DWORD result? I'm looking all over the docs but cannot seem to find them. Specifically, once in a rare while I get error code 13 in my loop - what is that?

The header file FSUIPC_User.h of course. Where else? Code 13 is a data format error, which one would certainly expect with multiple threaded accesses to the same data area.

This is really nothing to do with FSUIPC, it is part of the code provided in the SDK. Everything about everything concerning the interface in your program is in the SDK.

3. I see that there are no documentation on writing your own module, is there a reason why?

The question would be better phrased "why should there be?" As it is the "official" Microsoft SDKs which are published are the results of voluntary work by the FS team, they are certainly not a commitment. There never were any before FS2000 in any case -- everything was hacked. That's never stopped any number of add-ons.

You'd think the least microsoft could've done with all the addon's that rely on MSFS FSUIPC would be to supply you or anyone else with a module SDK.

They don't officially approve of any such methods of interfacing like this. They seem to believe that if it looked approved it would need support, and they cannot afford to support an open-ended never-ending always-extending interface such as FSUIPC's.

Regards,

Pete