Using PropFlags_Shared vs. PropFlags_SharedAtRunTime for Locals and FileGlobals

[Roxanne64]

Does anyone really understand the difference between PropFlags_Shared and PropFlags_SharedAtRunTime?

I’m using the PropFlags_Shared for both Locals and for FileGlobals.  I was originally using PropFlags_SharedAtRunTime but realized after some time that it was not working correctly.

I have read another forum discussion regarding this however it seems quite old and also didn’t really clarify the issue for me.

Here is a brief description of the File Globals PropFlags_Shared usage:

1. There are three UUTs being tested in parallel batch mode
2. File Global name: FG1 (with PropFlags_Shared)
3. Set program flow to OneThreadOnly
4. Measure room temperature and put value into FG1
5. Exit OneThreadOnly
6. All three threads now want to use the updated FG1
7. This seems to work fine as long as FG1 is PropFlags_Shared
   1. When I say works fine I mean that FG1 for all threads contains the correct value from batch 1 through batch N (each new batch measures room temp)
8. This does not work when FG1 is PropFlags_SharedAtRunTime
   1. When I say does not work I mean that FG1 for all threads contains the correct value only for batch 1, in batches 2 through batch N FG1 will not have the correct value for FG1 in threads 2 and 3, the value will only be correct for thread 1.  FG1 for threads 2 and 3 will retain the old value.

Thanks,

Roxanne

[mfaltin]

Hi Roxanne,

Without digging incredibly deep into the functionality of those flags, my initial suspicion is that while set to SharedAtRunTime the FileGlobal will be shared between threads only when the sequence starts. After which there is no sharing of the data. When set to Shared, the FileGlobal is shared continuously across threads throughout the sequence execution.

Best Regards,

Mitchell Faltin

Applications Engineer

National Instruments

www.ni.com/support

[Roxanne64]

Thank You Mitchell,

Can I assume that "shared between threads only when the sequence starts" essentially means the first time the variable is encountered?  E.g. The sequence starts running and at some point down in the code the variable is encountered, that point is where SharedAtRunTime will share across all threads?  All future places in the code the variable is not shared and all future batches the variable is not shared.  This is how SharedAtRunTime seems to be behaving.

[WireWeaver]

I'd recommend trying to clone a shared object at runtime and observe the difference in behavior between the two flags. For example:

1. Create a Sequence with a numeric FileGlobal "Global1"

2. Run Statement:

RunState.SequenceFile.Data.FileGlobalDefaults.SetPropertyObject("Global2",1,FileGlobals.Global1.Clone("",0))

3. Observe the difference in behavior when Global1 has the shared vs shared at runtime flag set.

Spoiler

With the shared flag, the cloned PropertyObject will maintain it's shared status even after the execution is complete

As for your actual use case, you should consider changing the scope of your FileGlobals in the Sequence File Properties instead of using the shared flag.

How Do I Share Data Stored in a File Global between Different Executions?

Hope this helps!

Trent

[Scott_Richardson]

The shared flags apply to when TestStand creates a clone of a property. Note that when the PropOption_DoNotShareProperties option is used with Clone, a shared flag is ignored.

If the original object has a parent property, that parent ownership is maintained, and the parent in the copy contains an alias to the original object.

One main use of shared flags in TestStand is to save memory when TestStand creates runtime copies of sequences, specifically all the properties under Step.TS.

Common examples of when TestStand clones property objects and use of shared flags will affect behavior:

• Creating an instance of a step type or data type
• Creating a runtime copy of an object:
  • sequence steps
  • sequence local variables
  • sequence parameters
  • sequence file globals

The shared at runtime flag applies only when the TestStand engine makes a runtime copy of a property, such as the runtime copy of a sequence. Performing a "runtime" clone is not exposed via the TestStand API.

Some considerations:

• If you use either the shared flag or shared at runtime flag on a variable, the edit-time copy of the variable will be shared with the runtime copy of the variables, so a big downside to using a shared flag on a variable is that run-time changes to the variable value will edit the value in the original file.
• Applying a shared flag to a local variable is effectively sharing the variable across all invocations of the sequence.
• Applying a shared flag to a file global shares the variable across all executions.
• A big downside to using the shared flag with type properties is that changes to an instance property can edit the underlying type.

Note: TestStand does not clone an object when it does a copy and a paste, it instead does a serialization and a deserialization, so the copy of the property does not have any sharing.

[juhatl]

" you should consider changing the scope of your FileGlobals in the Sequence File Properties instead of using the shared flag."

But this shares all FileGlobals. My wish is to share on some containers and have the edit time values changed, when runtime values do change.