Write to binary as reentrant VI

[zerotolerance]

This may be a simple answer, but here goes.

I am implementing a reentrant VI (with maximum 30 clones), and all clones will be writting information to the same file (call it test.txt) multiple times. The attached code prepares the file so that any information written to it will be appended at the end (i.e. the pointer position will be at the end).

I don't know how this would behave under a reentrant case. I thought of "getting" and "setting" pointer position of the file before the "binary write" happens, but I'm worried about the race condition. i.e. by the time I "get" and "set" the pointer, another "write" operation could've happened from another clone.

Any thoughts appriciated.

kas 

[Todd_Lesher]

The only thought I have is to not make it reentrant. Perhaps you could use an IPES or a semaphore to keep multiple VIs from writing to the file at the same time, but you might as well just use the file reference in a "linear" fashion.

[zerotolerance]

Well, using it as reentrant would greatly simplify my coding. If I'm still sticking to this, how would you implement the above example with IPES, semaphore or queues. 

Thanks 

Kas

[crossrulz]

This sounds like the exact place to NOT use a reentrant VI.  I would recommend using an Action Engine to manage your test file.

[zerotolerance]

Well, the data that each clone VI is handling could go up to 50MB (or more). I'm not very keen on using AE in this case, nor sending the data through a queue so that a non-reentrant VI or main VI saves it as the data comes. 

Thanks

Kas

[Todd_Lesher]

Oh, I see what you mean, now. The "write data to file.vi" will be called by different VIs and will write to different files. I thought you wanted them to write to the same file. As long as you pass in the file reference, reentrant is fine.

edit ...

Re-read the the OP - I don't see how you can expect multiple VIs to write to the same file at the same time.

[crossrulz]

You have 1 resource you have to protect.  That is the point of the Action Engine.  All you really need in the AE is a case to open the file, a case to close the file, and a case to save the data.  This way there is no conflict of multiple places trying to save data to the same file.  All the AE is doing to saving the data.  You can manage the data however you want in the reentrant parts of the code.

[zerotolerance]

"I thought you wanted them to write to the same file". 

Actually, this statement is correct.

[Todd_Lesher]

At the same time?

[zerotolerance]

"All you really need in the AE is a case to open the file, a case to close the file, and a case to save the data". 

As soon as you mentioned AE, I thought of using it in conjuction with data directly (hence my hesitation). Your solution however seems a way forward. 

Furthermore, would it be even better if I use the AE just to store/read the "refnum out" inside the while loop and keep the "write to binary" function outside the AE?.

Thanks 

Kas