Do Locks work the same after upgrade from Teststand 2.0 to 3.1?

[sahc]

It looks like the locks leak.  I have an array of ActiveXObjects each of which is a lock as station globals.  When I converted to 3.1 from 2.0 the station globals were not there in 3.1.  So I created an array of ObjectReferences. I am assuming these are the same and the name just changed.  Anyway the locks are not working now. That is when a thread locks a lock another thread still gets the lock and "comes on in" creating a cascade of run time error messages. I have a post expression on the get lock step (timeouts are enabled) : Locals.LockTimedout =Step.Result.TimeoutOccurred. And the next step jumps over the code if a timeout occured.

Any ideas?

Thanks,

Sahc

[Santiago D]

Sahc,

I believe the problem you are experiencing might be due to the timeout or scope of your lock.  TestStand will only release a lock under three situations: the lock is released explicitly in a step, the timeout is expired or the scope of the lock is reached.  I don't believe you are releasing the lock explicitly ,so it must be one of the other two situations.

Try running your sequence without the timeouts to see if you still receive the errors.  If the errors do not occur without the timeouts you might want to go back and increase the value of your timeouts.

If you find that the timeouts are not the cause of the issue, make sure that the scope of the locks you are using aren't being reached, and therefore, the lock is released.  The best way to go through this process is to set a breakpoint in your sequence and step through it one step at a time.

I am including a small example that demonstrates how different threads can share access to an array using locks.  If you run it with the parallel model one step at a time you will see that locks are operating correctly.

Regards,

Santiago D

NIC

[sahc]

In my application I need for the threads to do other work if the lock is unavailable.  So I try to get a lock with a 1 second timeout.  If I got the lock I do some work then release the lock with QuickRelease.  If I didn't get the lock I do something else.  I will include a sample sequence.  If I change the get lock to not allow timeouts then if thread A has the lock thread B will wait until it is released.  If I allow timeouts thread B waits the timeout value (set to 2 seconds in this example change the local  WaitTime of the Main Sequence to use another value) then returns.  But the value of the step result  Step.Result.TimeoutOccurred is ALWAYS False.  Under 2.0 the result acted as expected Step.Result.TimeoutOccurred is Falsee with no time out and True when a timeout occures.  Under 3.1  Step.Result.TimeoutOccurred is always False.

[sahc]

Opps looks like the sample didn't come through

[sahc]

I tried setting the Timeout is a runtime error flag.  And sure enough you get  a run time error when there is a timeout. So the only thing that doesn't work is the step result.  I made a simplified 2p0 sequence for comparision too.

[dug9000]

A bug was introduced in the 3.1 version of the SyncSteps.dll file. Attached is a fixed version of the dll with accompanying src code changes. Both of these files should go in your:

<TestStand>\Components\NI\StepTypes\SyncSteps

directory.

-Doug

[chasgl1]

Thanks, You are a lifesaver.

[sahc]

Thanks for the DLL fix earlier.  But I am wondering, does it always work or just usually work?  I am seeing symptoms that could be explained by the timeout indication usually but not always working. Have you ever seen a similar result?

thank you,

sahc

[dug9000]

It should always work. Basically, the step property just wasn't getting set if you didn't have the "timeout causes error" setting checked.

-Doug

[chasgl1]

Yes that is right, I had a silly code error that fooled me. Thanks again.