locals.resultlist while running vi asynchronously

[david_jenkinson]

Hi,

I can run the attached code configured as the module of a step in teststand, and get at the locals.resultlist size (and presumably contents, working towards that).  However when running this same code within a vi that has been launched asyncronously using teststands "run vi asynchronously" step type as the very next step in the same sequence, I cannot get a size above "0", which is in-accurate.  I am passing in "thiscontext" to the asynchronously running vi, as well as the the step which runs normally.  I suspect I need to pass in something different, if this is the cause, but I'm not sure what if it is.  Does anyone know  how I can access the resultlist from a vi that has been launched asynchronously in teststand?  Thanks for any help.

David Jenkinson

[david_jenkinson]

Forgot to attach vi...

[dug9000]

It's not thread-safe to access the result list from one thread, while another thread is adding items to it. You could pass locals.resultlist to your async vi, but it's not threadsafe to use it while another thread is adding to it, in any current versions of TestStand.

As an alternative, you could use the PostResultListEntry callback instead, and have that callback queue the results into a labview or teststand queue and then dequeue them from your asynchronous vi.

Hope this helps,

-Doug

[david_jenkinson]

I wasn't actually planning on writing to resultlist, only reading it from labview, so no race conditions can exist in this scenario.  Do you mean reading it from labview may lock it out in other threads, in some way?  Or what scenario should I look out for?  The queue idea would definitely work, as it is already a queued state machine, but concerned that the result list could get quite large and could result in a very large amount of queue information to pass. 

[dug9000]

Race conditions can exist even while reading as long as another thread is potentially editing what you are reading. For example, the underlying code for the result list array could be an stl vector. The memory for the stl vector could need to get reallocated when a new item is inserted. This involves copying the elements from the old block of memory to the new one. If you access the element before it is copied, while the vector is in an intermediate state, you could be accessing uninitialized memory and the behavior will be undefined (possibly leading to a crash). TestStand's PropertyObject API is not threadsafe with regards to structural changes such as array element insertion/removal in arrays of containers or structured data types.

The queue idea is that you enqueue the results as they are generated and dequeue them as they are processed. If your processor is keeping up then the queue should not get that large. If the processor is not keeping up then you might want a max queue size to slow things down anyway.

At any rate, if what you are really doing is writing a result processor and you are using TestStand 2012 or higher, you should consider writing a result processor plug-in for the process model instead of going this highly custom route.

Hope this helps,

-Doug

[david_jenkinson]

Hi,

Thanks for the insight.  What I'm actually doing is writing a vi to simply display results of a certain step type, in a separate gui, prior to the end of the test, nothing super fancy.  It is a long duration test.  It's simply to get an idea of how things are progressing, no processing or anything, simply display.  So adding a custom report to the process model would only happen at the end, which we would already know anyway based on the current result types we are utilizing (html and database).

I have found a workaround to my original issue, in case anyone might find it useful.  I am saving "ThisContext" from MainSequence to a Fileglobal prior to launching the asynchronous vi, then pointing sequence context of the asynchronously launched vi to this fileglobal.  I can then access the locals.resultlist of MainSequence from the asynchronously launched vi seamlessly.

I understand sequence context to be a simple pointer to an area of memory.  Of course I can't know this for sure as I don't have access to the teststand source code.  I'll probably call NI support and run this by them to see if anything they are doing on their end might be compromised by me querying resultlist over and over again from labview.  Thanks for your time.

David Jenkinson

[dug9000]

You might run into reliability issues doing things this way due to race conditions. Have you looked into on the fly report settings? Report generation doesn't have to wait until the end, there is a setting to generate reports and log results while the sequence is still running.

-Doug