Lock Step- Dumb Question

[subsolanus]

Should it look like this?

[ee-jallen]

Your image is showing the Synchronization settings for the Step and would equate to putting a Lock on your Lock step.  I have never done that before and I haven't seen any Lock steps in NI's own Model Support plugins do that.

What process model are you using?

You can easily prove if your 2 LabView steps are being executed by 1 thread at a time by:

• put a breakpoint on the UpdateBurninData step
• Run the sequence using process model....and if you are running multiple "sockets" (threads) you should only hit the breakpoint in each socket one at a time.  If you end up seeing all the sockets paused then all threads are could theoretically be trying to run those steps at the "same time".

[subsolanus]

Are you referring to the first image when you say it equals putting a lock on the step?

This is the situation I am questioning.

[ee-jallen · Accepted solution]

---

@subsolanus wrote:

Should it look like this?

---

In your last image.  That setting is the Step - Synchronization settings.  You don't need that and I have never seen it used. In other words, I have never seen a Lock step setting used on a Lock Step; it just seems redundant to me.

If you are running multiple sockets (threads), the first socket to obtain the Lock will continue and prevent the others from running until the lock is released, then the next socket will obtain the lock. 

What process model are you using?  Sequential, Batch or Parallel?

[subsolanus]

What is happening overall is that when other sequences are running (everything is multithreaded, several UUTs running in parallel), I get run Time Error pop ups where the error statement says that a database file cannot be written to because it is locked.

This pops up in the middle of a random sequence where the database isn't even being used.

It makes me think that in two other threads, the database is trying to be written to and the database write process is not locked properly. The database provider is MS JET.

This occurs randomly every few days.

[ee-jallen]

---

@subsolanus wrote:

What is happening overall is that when other sequences are running (everything is multithreaded, several UUTs running in parallel), I get run Time Error pop ups where the error statement says that a database file cannot be written to because it is locked.

This pops up in the middle of a random sequence where the database isn't even being used.

It makes me think that in two other threads, the database is trying to be written to and the database write process is not locked properly. The database provider is MS JET.

This occurs randomly every few days.

---

What process model are you using?  Sequential, Batch or Parallel?  Are you spawning your own threads or letting TestStand handle it via the process model? Or are you running the sequence  from a custom application using TestStand API?

[subsolanus]

So the checkbox is there to provide a lock function to some other step besides a Lock. Correct?

I am very new to TS, obviously.

[subsolanus]

I don't know how the threads are being generated. That is in another sequence I haven't looked at yet. I will check. These sequences were written using the Sequence Editor.

[ee-jallen · Accepted solution]

---

@subsolanus wrote:

So the checkbox is there to provide a lock function to some other step besides a Lock. Correct?

I am very new to TS, obviously.

---

Yes, each "Step" type has a built-in option to lock.  The "Lock" Step, because it is a step, also has the built-in option to lock.