Wait structure overhead

[Bublina]

Hello,

I usually make tasks (I call these slaves) in my program with wait structure that processes user events to allow for program control. It is very comfy, since you only need to fire one event and all slaves will process it, eg "start measure" and so on.

These slaves do nothing, once I need them to do something like process queue or stuff, I programmatically change the wait structure timeout to zero and once timed out they start working and bounce back to wait and so on.

Recently, I was wondering about the overhead the wait(0) brings, and it is quite big ?!?!?!?

To bash this down, here are few examples :

First standard, how many iterations do I get without any sync structures. Result = 3 750 000 iterations

Second, to see the wait structure overhead. Result = 630 000    This was quite shock, I thought it would be around 1/3 of the waitless loop.

Third, a bit shocky. Result = 34 000 So the wait structure overhead is not so huge...

I was trying to find a proposed method to control bigger architectures, but didn´t. I would like to know, if it is genrally OK to use the wait structure as control mechanism for VIs with around 100s of iterations per second, or is it better to implement these as one queue consumers, where the data might differ, just like it is in actor framework (not so comfy)?

[crossrulz]

The thing with the event structure, anything with a timeout, and a wait with 0 wired to it is that you are telling the OS to let other stuff run for a little bit.  You are essentially sharing the CPU.  For most operations I've ran into, this is desirable.  For those that need to process a lot of data as fast as possible, you should use another loop with no timeout/timing functions.

[johnsold]

Not sure what you are trying to do.

Wait(0) only causes the execution to pause long enough for the LV scheduler to check to see if another process is ready to execute.

The loops with event structures should probably not have a timeout case at all. Then there is no wait overhead except a few CPU cycles when the loop starts executing.  When an event occurs the event case executes and then the loop waits for the next event.

Similarly, the queue loop can use infinite timeout with essentially no overhead.  The queue with a timeout will generate a Timed out? boolean so it is reasonable that the overhead is a bit larger.

Lynn

[Thoric]

In none of your examples are you calling the Wait function, you are simply checking the current system counter value. The wait function looks like this:

I'm not sure simply checking the system clock count will actually cause any thread swapping to allow other processes some CPU time.

And as everyone else has posted, it's not clear what you are actually trying to do?

[Bublina]

---

@crossrulz wrote:

The thing with the event structure, anything with a timeout, and a wait with 0 wired to it is that you are telling the OS to let other stuff run for a little bit.  You are essentially sharing the CPU.  For most operations I've ran into, this is desirable.  For those that need to process a lot of data as fast as possible, you should use another loop with no timeout/timing functions.

---

Sure, agreed. What do you do when you need to have a VI, that processes a lot of data + you need to control it somehow.

You can either use one queue with different datatypes, eg cluster(enum, variant) - this means you only have one syncronization object through the whole VI (Queue dequeue) and no timeouts what so ever.

Or you combine the wait structure and the data queue. This brings a bit more programming comfort.

Here is my question again, it gets lost in the context of the post I see 🙂

I would like to know, if it is genrally OK to use the wait structure as control mechanism for VIs with around 100s of iterations per second, or is it better to implement these as one queue consumers, where the data might differ, just like it is in actor framework (not so comfy)?

[Bublina]

---

@Thoric wrote:

In none of your examples are you calling the Wait function, you are simply checking the current system counter value. The wait function looks like this:

I'm not sure simply checking the system clock count will actually cause any thread swapping to allow other processes some CPU time.

And as everyone else has posted, it's not clear what you are actually trying to do?

---

I made those examples just see the how much overhead the checking of incoming events/elements costs in terms of performance.

[JÞB]

---

@Bublina wrote:

I would like to know, if it is genrally OK to use the wait structure as control mechanism for VIs with around 100s of iterations per second, or is it better to implement these as one queue consumers, where the data might differ, just like it is in actor framework (not so comfy)?

---

Honestly, I agree that the Actor Framework is much less "Comfy."   On the other hand, I will not even begin to debate it on a Computer Science based "Best Practices" argument. 

So it really boils down to one question, Did you want to build This or build That?

Yes, It is OK to use the Wait structure.  The actor Framework is better software engineering

[Mark_Yedinak]

I try to avoid polling operations if at all possible. Your use of the Wait(0) or queue timeouts are effectively implementing polling solutions. I prefer to use event driven systems that will use either queues (with no timeouts) or user events. If I have regular processing that can occur that is not driven by the events or messages I would probably create an internal message handler that people often call a queued state machine. I would then create a separate loop that its only purpose is to wait for the external event/message. When it receives it will post that to the internal processing queue.

The actor framework is also a good design pattern.

[crossrulz]

I'm with Mark on this one.  I tend to use Producer/Consumer architectures when I have a lot of processing to do.  The QSM Mark described is really an extension of the Producer/Consumer.  And these work quite well.  I don't like using the Timeout case of the Event Structure at all.  But there are rare occasions I will use it.  Using a timeout is like polling, which kind of defeats the point of the event structure.

[Bublina]

---

@JÞB wrote:

---

@Bublina wrote:

I would like to know, if it is genrally OK to use the wait structure as control mechanism for VIs with around 100s of iterations per second, or is it better to implement these as one queue consumers, where the data might differ, just like it is in actor framework (not so comfy)?

---

Honestly, I agree that the Actor Framework is much less "Comfy."   On the other hand, I will not even begin to debate it on a Computer Science based "Best Practices" argument. 

So it really boils down to one question, Did you want to build This or build That?

Yes, It is OK to use the Wait structure.  The actor Framework is better software engineering

---

Frankly, I can decide on what to use or not to use on my own, when in doubt, I can allways test it. The puprose of such question is more likely targeted on other users and their/yours programming habbits.

There might be a day in near future, when NI decides to rework the wait structure (they really can do that, look at the wish list around it) and as reimplemented, it will carry much more overhead or wont be suitable for what I do with it for any other reason. They will not do it if most users tend to use it the desribed way.

If there was any architecture guideline supported, I would use it.