FSUIPC with threads (it's possible?)

[Leonardo Freschi]

Hello,

I'm programming with FSUIPC dll, and I'd to use threads, but I'm getting some troubles to do that.

My question is if it's possible to use threads to read many variables on FS in the same time using the function FSUIPC_Read, passing in parameter dwResult, without use waits in any thread. The dwResult variable appears to be overwrite in each acess.

Ty,

Regard,

Leonardo Freschi.

[Pete Dowson]

I'm programming with FSUIPC dll, and I'd to use threads, but I'm getting some troubles to do that.

My question is if it's possible to use threads to read many variables on FS in the same time using the function FSUIPC_Read, passing in parameter dwResult, without use waits in any thread. The dwResult variable appears to be overwrite in each acess.

The interface from an application process into FSUIPC doesn't care about threads, but when you open the link (FSUIPC_Open) only one shared memory area is used for all of the exchanges. So you either must keep all the Reads and Writes in one thread, or synchronise them so there is no possibility of an overlap.

The best thing to do is have a thread running which does all the FSUIPC_Read and FSUIPC_Write actions, with one FSUIPC_Process call per cycle. There's no point in having multiple threads reading and writing separately. Only the Process call actually does anything -- all the Reads and Writes are doing is building the request list in the shared memory area.

Regards

Pete

[mgh]

Is it possible to have multiple instances of FSUIPC executing at the same time - each having its own shared memory area?

[Pete Dowson]

Is it possible to have multiple instances of FSUIPC executing at the same time - each having its own shared memory area?

You could, but not using the library, because the FSUIPC_Open, will, each time, try to open the same shared memory area. The C source is provided, however, so you can make your own interface code with each thread creating its own memory mapped file with a unique name.

I realy don't see the point, though. Why would you want to do such things? The most efficient way of interfacing to FSUIPC, for both your program and for FS performance, is to do a single regular FSUIPC_Process once per period, with that period being at most frequent something similar to the FS frame rate.

A single specialised thread doing the FSUIPC operations and storing the data for the other threads is surely the most efficient. I would hope you are not considering each of your threads doing individual FSUIPC_Processes for individual reads or writes? That is extremely inefficient. Remember, each time you call FSUIPC_Process you are forcing Windows to transfer control back and forth between processes, an immense waste of time if done needlessly.

Regards

Pete

[mgh]

I'm not sure why i might want to do it either, but i've run two instances of FSUIPC in separate loops satisfactorarily.

Each Read/Write statement will have an overhead, but is the overhead on actually transfering data dependent on the volume of data transfered?

[Pete Dowson]

I'm not sure why i might want to do it either, but i've run two instances of FSUIPC in separate loops satisfactorarily.

If you mean two "FSUIPC_Open" instances, then both will be using the same Memory Mapped File space so you'd run into trouble if both "loops" wre trying to add Read or Write requests at the same time -- they'd corrupt each others data.

Each Read/Write statement will have an overhead

No, not really any at all. All the Read and Write requests do is add a request to the data. The only call which does anything taking any time is the Process.

but is the overhead on actually transfering data dependent on the volume of data transfered?

Not normally, and certainly not compared to the inherent transaction time, that of sending the message, switching processes, processing the message and swapping back again when completed. With most normal data sizes, ranging from a few hundred to a few thousand bytes, there's no data size differences. Anything likely to slow that down will be requests which actually cause some action to be invoked in FS, like saving or loading files or sending weather requests off and waiting for results.

You can experiment with data sizes and so on quite easily using FSInterrogate, from the SDK. You can actually select the entire set of offset, nearly 64kb, and have it transfer a short intervals. The main thing then slowing things down is its display updating, not the transfers so much.

Regards

Pete

[mgh]

If you mean two "FSUIPC_Open" instances, then both will be using the same Memory Mapped File space so you'd run into trouble if both "loops" wre trying to add Read or Write requests at the same time -- they'd corrupt each others data.

i used the published code from the SDK to create a C++ class and then converted it to a Borland C++ component. I dragged and dropped two components into my application and put each in a separate timer loop, running at different speeds. Each loop returned the expected values.

[Pete Dowson]

i used the published code from the SDK to create a C++ class and then converted it to a Borland C++ component. I dragged and dropped two components into my application and put each in a separate timer loop, running at different speeds. Each loop returned the expected values.

If the timer loops were in the same thread there's no problem with sharing the same memory space for the accumulated requests as the Read ad Write requests cannot overlap. You were asking about threads were you not?

Pete

[mgh]

I wasn't talking about threads - only if more than one instance of FSUIPC can co-exist.

[Pete Dowson]

I wasn't talking about threads .

I'm sorry, but the basis of the entire thread arose from you asking about threads. Remember?

I'm programming with FSUIPC dll, and I'd to use threads

About this, though:

- only if more than one instance of FSUIPC can co-exist

It won't be more than "one instance of FSUIPC". FSUIPC is the DLL running inside FS and there can only be one of those. You just mean FSUIPC open links. And for one process there's only one, no matter how many FSUIPC_Opens you make, UNLESS you change the interface code to alter the name of the Memory Mapped File each time. All you are doing is making multiple uses of the same Memory Mapped File for different loops -- it is only one link to FS. The file name is generated from the Process ID. That is necessary to ensure it is different from those used by other applications running at the same time -- otherwise data from different processes would get mixed up and corrupted.. You'd need to add something different to the name to make more than one.

The only reason the data doesn't get mixed up and corrupted in your case with a single thread but separate loops is that the Read and Write access to the Memory cannot occur simultaneously or overlap -- the single thread runs consecutively, no concurrency. Threads, like Processes, are different.

But there's absolutely no point. This discussion is really futile. You can't make things run any better, only worse! I don't understand why you persist after all I've explained to you.

Regards

Pete

[mgh]

I'm sorry, but the basis of the entire thread arose from you asking about threads. Remember?

Leonardo Freschi asked about threads: I asked about running multiple instances. Remember?

[Pete Dowson]

Leonardo Freschi asked about threads: I asked about running multiple instances. Remember?

Ah, sorry -- to me, one thread, one subject. I didn't even notice change of author. You don't when answering so many threads per day.

Anyway, all the answers are now provided for both questions.

Regards

Pete