Remove 'Background priority' from VI Properties/Execution since it is ignored anyway

[SteenSchmidt]

I suggest the Background priority (lowest) option be removed from the priority selector in the Execution page of VI Properties:

The reason for this is that NI (much to my surprise) confirms that this execution priority is ignored. A VI set to background priority simply runs at normal priority:

http://forums.ni.com/t5/LabVIEW/Is-background-priority-in-VI-Properties-ignored/m-p/1637750/highligh...

Cheers,

Steen

[ShawnMahon]

Using that setting actually does have *some* affect.  It is true that it won't spawn off a lower priority thread, the VI will be in the same queue & thread as the VI's that are normal priority.  However, it will yield to the normal priority VI's in the run queue.

[SteenSchmidt]

There is an execution-queue for each execution system, right? So prioritization always takes place inside this single queue anyway. If you say that "background priority" will yield to "normal" priority in the execution queue, just like "normal" will yield to "above normal" and "high", that means the setting for "background priority" has exactly the advertized effect. This is the complete opposite of what NI informed me of in the forum thread I link to in my OP. So which is it - does "background priority" have the advertized effect or not? In any case some documentation needs to be updated, because currently contradicting information is present online.

/Steen

[ShawnMahon]

It works the way I described above.  It will not spawn a new thread, but normal priority VI's will be picked off the queue to run first before any background priority.

[SteenSchmidt]

Isn't that the way every other priority works in any given execution system?

One run queue exist for each execution system (instrument I/O for instance). N threads exist for this run queue to use (the execution system threadpool). An individual threadpool exist for each execution system. All priorities for a given execution system ends up in that execution system's run queue, and is assigned an idle thread from its threadpool, highest priority first, same priorities go round-robin. The only code that spawns new threads to the threadpool are timed structures, all other (user)code runs in the threads defined from the start in the threadpool. How many threads exist from the start in each threadpool depends on which execution system it is, and to some extent on the current configuration of LabVIEW.

If my description of the scheduling system above is true, and what you say about background priority is also true, then background priority behaves as it should.

Note I'm not sniping at you, I'm trying to understand this since it's a very important aspect at the level of architecture I'm often deployed - and since I read conflicting NI documentation regarding this.

Cheers,

Steen

[SteenSchmidt]

> AQ: nevermind.

Hey, what happened? Your explanation was right on point: The missing link for my understanding is the difference between the thread context and execution system context. Background priority is running together with standard priority implementing non-preemptive multitasking in the thread context, but preemptive multitasking in the execution system context. That's easy to understand, and explains the (my) confusion. That way all documentation is right, albeit quite opaque.

Did I say something wrong for you to erase your explanation?

Best regards,

Steen

[AristosQueue (NI)]

My explanation was unnecessary. I hadn't refreshed my screen to see your reply.