Write to binary as reentrant VI

[zerotolerance]

"At the same time?"

lol, yep. But going from your sugestion, I need to properly queue this operation.

Thanks 

Kas

[zerotolerance]

crossrulz

Is this roughly what you had in mind?

Thanks 

kas

[crossrulz]

---

zerotolerance wrote:Is this roughly what you had in mind?

---

That is pretty muich exactly what I meant.  Some minor tweaks though:

1. Don't use the case structure to skip code for an error.  Those functions will skip on an error anyways.  Why add the extra check?  Plus you will want the close function to work even if there is an error (which it does on its own already).
2. Instead of wiring the file out through all of the structures, just wire the indicator straight to the control.
3. I would move your constants inside of the cases so it is more evident what they are for.  (this is more of just my opinion though, don't take it as a hard rule)

[zerotolerance]

Hi.

Further to this, I have sinced modified the original idea, where openning and closing the file is done outside the reentrant VI. So, would the following subvi made as non-reentrant work? or is "write to binary" non-reentrant on its own.

Thanks 

kas

[crossrulz]

The file access itself is probably non-reentrant (or at least we hope).  I still would recommend going with the AE so you don't have to pass the file reference all over the place.  It is best to make sure the resource is protected.

[zerotolerance]

"The file access itself is probably non-reentrant (or at least we hope)" 

It would be nice if someone confirms this.

"It is best to make sure the resource is protected."

Correct. I guess I'm just trying to think of ways of limitting the "botleneck" without compromising the stored data. 

Kas

[FraggerFox]

---

@zerotolerance wrote:

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 

---

I couldn't check your VI since I have LV2010.

As the write to file labview api itself is non-reentrant, there won't be any race conditions here, from my opinion. The clones will wait for each other to write the data.

I quickly tried this out by opening 40 clones of a VI accessing the same file reference, and all of them showed up their data, though the sequence of writing data was not consistent, which is but expected. These clones were writing data using the file reference, which was opened before the write data started, and closed after all the clones finished writing the data.

Having said that, using AE is still recommended, as a good programming practice.

[FraggerFox]

---

@zerotolerance wrote:

Hi.

Further to this, I have sinced modified the original idea, where openning and closing the file is done outside the reentrant VI. So, would the following subvi made as non-reentrant work? or is "write to binary" non-reentrant on its own.

Thanks 

kas

---

This one inside a reentrant VI would work, as mentioned by me in the previous post.

[zerotolerance]

---

FraggerFox wrote:

As the write to file labview api itself is non-reentrant.

---

Thanks for confirming this. Logically speaking it makes sence for this not to be a reentrant.

If you haven't yet deleted the VI's, would you be able to post the example you spoke of? It'll help me see if the example you have is similar to what I have here.

This may be a different question to the thread but since its for the same project I'll risk  asking the question here.

I'm sending certain values "settings" in the cluster form from main VI to these reentrant VIs at the very beginning, and when reentrant finishes, they send a "cluster" of data (other than those saved) back to main VI. I'm achieveing this through queues, where:

1. I'm openning reentrant VI

2. Get its clone name and create a queue of that name in the main VI (I'm only closing this queue when the reentrant sends a message back saying its done)

3. Sending data through this queue (including the queue name as string where the clone name should reply to when finished).

4. The clone now opens up and creates a queue with its own name and reads the data from the main VI.

5. clone closes this queue. 

6. After operations, the clones creates another queue based on the queue name passed from the main VI, this is so that it sends messages/data back to the main queue saying that its done. 

7. The main queue then recieves the message from the particular reentrant VI, and closes the initial queue that was created "from point 2.". 

I'm just wondering how would you guys implement this type of situation. I'm hoping there may be some good practices and ways that can minimise the amount of queues that I'm creating just so that I can send messages between each reentrant VI and main VI.

Thanks guys

Kas 

[FraggerFox]

---

@zerotolerance wrote:

4. The clone now opens up and creates a queue with its own name and reads the data from the main VI.

---

That would definately eat up the memory, and is not a good practice.

I still have the example which I was talking about and posting it. The example will show 4 clones spawning over 10 iterations, and just to check the timing, I included a 32 bit precision seconds time in the log.