NXC: wait(1) for safe task (scheduling) control needed?

[HaWe]

how shall I write a 20-task subsumption-test-program if it is not the 20-task subsumption-program itself? How should I recognize if maybe 1ppm of the data are corrupted or get lost and otherwise not?

[mattallen37]

Well, I don't understand exactly what you want to be able to do, but you should be able to come up with something to test it. If you can't, then why don't you build you're program the way you want it, and if you get errors, start trying to fix them then. Normally I don't spend a lot of time debugging my programs before I find a problem.

Typically, a 1ms wait is not a big issue for loops, at least not most of mine. 1ms CAN be a substantial amount of time, but it depends on perspective. Most user control related loops of mine, as well as display loops, have 20-50ms wait functions. I don't notice any difference most of the time. The only program of mine I can think of that would be dramatically affected, is my encryption/decryption program(s).

[HaWe]

20 tasks* 1ms = 20ms for each loop. That's quite a lot. So I'd prefer to know it for sure if I need to do it or not.

Do I need to insert a
Wait(1)
into each task for a safe task (scheduling) control?
I'm actually curious because if I needed to, I'm afraid of waisting 20*1ms for each time slice scheduling round - (sorry don't know the exact English term)

my question was not about "a good idea" but about a definite answer to "unnecessarily needed or not"

[mattallen37]

20 tasks* 1ms = 20ms for each loop. That's quite a lot. So I'd prefer to know it for sure if I need to do it or not.

Actually, if it is for user-interface, 20ms loop waits is something I would almost always use. If it is just NXT processing, and completely based on efficiency/speed, then I can understand your concern. Really though, 20/1000ths of a second is not much time when compared to human processing of surroundings (your eyes update about every 83 ms).

So, are you just using sub routines (or custom built functions) and a control loop? If so, then that is not multitasking, that is simply running everything in a loop. You shouldn't need to wait any in that case. To go from one sub to return, to another any number of times, you don't need to wait at all. If you have more than one control loop, then you MAY want to use a wait, but again, I don't think you need to.

[HaWe]

I use everything you can imagine: up to 20 tasks and lot of normal and lot of safecall functions and some inline functions, too ;)
So I need the definite answer to my question (no "think", no "probably" no "may", no "want"):

Do I need to insert a
Wait(1)
into each task for a safe task (scheduling) control?
I'm actually curious because if I needed to, I'm afraid of waisting 20*1ms for each time slice scheduling round - (sorry don't know the exact English term)

[mattallen37]

How about could, might, likely, possibly...

If you want a definite answer, the answer is the ternary logic ( ) answer of "UNKNOWN". If you want a boolean or binary logic answer, I am afraid there is no definite answer I can give.

The only way to know, is to test it. We can't know how the NXT is programmed, and there are an infinite number of possibilities.

[HaWe]

Thx matt, I understood that YOU don't know the definite answer yet.
Maybe someone else has got it (except Xander, I "can imagine" that he's right)

Do I need to insert a
Wait(1)
into each task for a safe task (scheduling) control?
I'm actually curious because if I needed to, I'm afraid of waisting 20*1ms for each time slice scheduling round - (sorry don't know the exact English term)

No, it is not necessary since it's pre-emptive, however, it is better to insert a wait where you know you're going to wait for something anyway.
- Xander

[muntoo]

This is turning into a flame war...

20 tasks* 1ms = 20ms for each loop. That's quite a lot. So I'd prefer to know it for sure if I need to do it or not.

Or rather:
20 tasks * 1ms - 20 tasks * avg_time_per_task

Don't forget to subtract the time it takes to execute all those 20 loops minus the Wait()s. While a task is still waiting, it's moved to the bottom of the task queue every time its time slice comes.

It depends on how CPU intensive all your tasks are. If each of them takes 1 ms to execute on average, then adding those Yield()s will not affect your program speed. In fact: it may even help regulate how many ops are spent per task. *

Another possibility: You can add a timer to measure if 1ms has passed since the last time you used Wait(1). If not, continue looping. If 1ms has passed, apply a Wait(1). The problem (if one exists) is solved. If you want to be on the safe side (which I think you do, since you asked this question - psychology 101^42), you'd do this.

* The default is 20, but you can change the priority, as I mentioned earlier. (I can't remember how.)

---

As I've said, only John Hansen knows (for sure) because only he's got the latest copy of his EF. ** Try PM-ing him to see if he'll post an answer to benefit us all.

** He did say he'll be setting up a SVN, and when it comes out, then we [translation: me] can continue trolling our discussion.

--

If you want a [partially ] non-elvish answer, I'd say add the Wait()s for tasks you don't want running too often, and leave the "main" ones alone.

"Go not to the Elves for counsel, for
they will say both no and yes." - says Frodo to Gildor

Smart elves.

[HaWe]

I'm only talking about the highest.priority tasks, and unfortunately your reply doesn't answer my question...

[afanofosc]

Sadly, I don't know for sure. If I were writing a program I would not use 20 tasks unless I was a masochist. There are a lot of really complicated Windows programs that do not require 20 separate threads to do everything that needs to be done. On any real-world NXT-based robot do you really have 20 completely separate things that each need to have a dedicated thread running simultaneously with every other thread?

Inserting a wait doesn't buy you a whole lot more than a known spot at which the current thread will definitely stop executing long enough for another thread to get a piece of the CPU pie. But it will definitely eventually stop executing at some point since the firmware VM task scheduler will enforce a round robin pass through all 20 threads after each one has executed 20 operations. Using mutexes to protect calls to shared functions (i.e., safecall) will complicate this somewhat.

You can use a Wait(0) if you like. All it does is yield to another task without causing the current task to wait a full millisecond before it can execute again. Perhaps I should change Yield to use 0 instead 1?

John Hansen