FSUIPC and multi-thread for Pete

[zofo]

Hello,

I wrote a small utility with VB.Net and C# to pause FS with conditions.

Today , I’d like to add logging functions.

To avoid freesing the interface, I use another thread and timer to get and FSUIPC data.

I used two independant connections to FSUIPC.

The condition timer and log timer are set to read each second.

When the two threads are working in parallel, I get correct data only one time on three or four.

In a another thread, I wrote data each five seconds and have no problem.

An idea ?

A problem with FSUIPC and multi-thread ?

Thank you for your reply.

[Pete Dowson]

I used two independant connections to FSUIPC.

I don't understand why you'd need two -- after all it is only FSUIPC you are pausing, not your own threads/program, surely?

When the two threads are working in parallel, I get correct data only one time on three or four.

The problem is likely that, since both threads are in the same program, the memory-mapped filename generated in the SDK code you are using will be the same -- it uses a Process ID to make it unique, but both threads are in the same process.

If the identifying string is the same in both cases, the memory-mapped file being used to transfer data back and forth is the same in both cases. Each time you use an FSUIPC_Read or FSUIPC_Write call you are altering data in the SAME memory area but incrementing different pointers.

If you really do need two separate links to FSUIPC in one process you most certainly will need to delve into the interface code you are adopting from the SDK and add the thread ID or some other differentiating value to the string generated to make the name. Do NOT change any of it up to and including the Process ID or FSUIPC will nto be able to identify you.

However, I do think you are making things too complicated. It will be far more efficient to concentrate all your FSUIPC access in one thread, with one link, and channel all your requests and settings through that.

A problem with FSUIPC and multi-thread ?

Not with FSUIPC, which is completely unaware of threads in processes outside of FS. You are using interface code in the SDK which generates unique strings as memory-mapped filenames and which uses the Process ID to do this. Opening more than one in the same Process uses the same memory-mapped file. You need to use semaphores to coordinate access and maintain common pointers to use that file correctly.

Check the source code you are using in the SDK. You will see what I mean.

Regards,

Pete

[pellelil]

I am currently updating the Delphi Part of the SDK and in the process i have turned it into OOP and in the process I have aimed to make it Thread-Safe (I realize that Delphi is not your development tool however you could use the same method).

I have actually made 2 Classes and its only the one that actually communicates with FSUIPC/WideFS (hence this is the only one manipulating the MMF). The child-class has its own buffer and then you call its "Read"/"Write" method all it does is to "prepare" the data within its own buffer that should eventually go into the MMF. When you call the child-class's "Process" method it uses a "Critical Section" to ensure only one is using the "Master-Class" (the one that communicate via the MMF), and the local buffer of the Clild-Class is transfered to the the MMF and the Process of the Master is exectuted and the "Critical Section" is left.

This way I can have several Child-Classes in the same program and I can prepare data to be read/written using their local buffers. Only when I try to "Process" data i have to ensure the actuall MMF/FSUIPC communication is protected (Thread-Safe).

Don't know if this would help !?