Muti-threading

[Ryan M.]

I want to know everyone's opinion on threading. Would you like to have the ability to create threads for the RC, or are you happy with the way the things are now?

(For those of you who don't know, having threads is a way of allowing mutiple things to be happening in your code at the same time and independently.)

[Grommit]

I'm not certain, but I doubt this would substantially improve performance.

What I need is a math library, readily accessible... how can one live without exponentials, hyperbolic secants, and zeta functions!?

I realize that many are available (like the open source Sun Microsystems library, which we ended up using) but it is difficult, with a large library, to pick out the functions you actually need. A library in the firmware or somehow better accessible, with only the functions that one really would need, like trig/powers, would be quite welcome.

[Ryan M.]

Originally Posted by Grommit

I'm not certain, but I doubt this would substantially improve performance.

I'm not necessarally thinking of performance, in fact, unless done well, this might slow it down some. (very little) I'm really thinking of the advantages of being able to have, say, a thread that is continuously running, watching encoders on the wheels and ensuring they are turning at the correct rates for the desired turn/staight.

[piotrm]

I guess that it might be nice to have them just as another option. It is nice to have more than one way of doing things. I personally never use threads for anything. But then I don't do robot programming (but if I did robot programming, I wouldn't use threads anyway).

[Xufer]

it wouldnt be too much of a problem to have and use threads but do oyu really have that much use for them ? Theres not really that many things you would need to have running at once? I think it would be agreat idea but I am at a loss as to what would it be used for. I also dont know what kinda crazy programming things you guys do some times.

[10intheCrunch]

While it might be cool, interrupts seem capable for the tasks we need to do. Threads would probably just complicate things, and while I doubt I'd use them, I don't really care if they are there and someone else wants to...

[Mr. Lim]

Originally Posted by Texan

I want to know everyone's opinion on threading. Would you like to have the ability to create threads for the RC, or are you happy with the way the things are now?

(For those of you who don't know, having threads is a way of allowing mutiple things to be happening in your code at the same time and independently.)

Since the current controller supports timer interrupts, you could code a simple OS to do pre-emptive multi-tasking and have prioritized threads that way.

Really, I doubt anything is stopping you, other than having capable programmers to be able to deal with concurrency issues. I wouldn't however make threads available by default though. With 6 weeks to build, I know that I would much rather spend my time getting the robot working rather than fighting with concurrency =).

Which means my vote is for keeping them the way they are.

[Ian W.]

Originally Posted by Texan

I want to know everyone's opinion on threading. Would you like to have the ability to create threads for the RC, or are you happy with the way the things are now?

(For those of you who don't know, having threads is a way of allowing mutiple things to be happening in your code at the same time and independently.)

Threads are overkill, right now, for what we're doing. Ask this question in a few years, and I might have a different answer for you ;-).

For now, I think adding threads just adds needless complexity to the coding, we already only have a day to actually test programming, let's keep it as simple as we can.

[Gene F]

As a way to approximate multiple threads, we use multiple finite state machines. One for the tracks, one for the arm, one for the wrist, etc. Each one gets called every pass through the main loop. It allows multiple threads of conciousness without the overhead of task switching. It does take a bit more thought to come up with the state machines and the coordination mechanisms.

[Astronouth7303]

It would be cool, but it complicates programming. Even on PCs, this is true.

[Raven_Writer]

Personally, I dislike the idea. I was working with threads on my FIRST Editor project, and it's very unsafe. You have to make sure the thread is closed (securely), or else there will be many problems arisen.

Picture this: 10 seconds left of the 2nd finals match, and you're 1-0, score is 40-5 your favor. Then, at 5 seconds, your robot which was supposed to close a thread, didn't. Robot goes *POOF* into a big flame.

Even if FIRST, IFI, and whoever is our supplier next year saids they made it to where the threads close safely all by themselves, there's never a 100% chance that it will close safely.

I dunno, I just feel it's more trouble than it's worth. Not to mention the fact that a lot of things would have to change.

[Astronouth7303]

What I said. it would be cool, but I would probably just use one thread because of the complexities.

[Rickertsen2]

Whats to prevent you from implementing software threading now? Absolutely nothing at all. If you really feel you need threading ,then write yourself some threading. On an architecture this small, the overhead of full threading capabilites usually outweighs the benefits of threading.

I personally do not think threading is necessary at this point. If at any point it were necessary, then i would say write your own. We implemented a few processes that ran in the background, but i would hardly call it threading.

[Ryan M.]

Originally Posted by Rickertsen2

Whats to prevent you from implementing software threading now? Absolutely nothing at all. If you really feel you need threading ,then write yourself some threading. On an architecture this small, the overhead of full threading capabilites usually outweighs the benefits of threading.

I personally do not think threading is necessary at this point. If at any point it were necessary, then i would say write your own. We implemented a few processes that ran in the background, but i would hardly call it threading.

I'm considering it. Or at least a psuedo-threading that would appear to the "threads" as either a pre-empitive or cooperative threading environment. I know that the RC has enough power to handle the threads. The RCX from LEGo Mindstorm uses a chip with similar specs and that handles threading fine. I was just curious on people's opinions.

[jdong]

Perhaps implemented by a vector of callback function pointers, itinerated by an interrupt loop?


Pre-emption won't be much of a possibility, but doing little chunks of code would be possible.