Asynchronous Code Design

[jkoritzinsky]

I've noticed that there is a lot of use of the Thread class in our projects here, especially in this repository. The Thread class is actually very resource intensive (mainly because threads are resource intensive). We should take a look at the asynchronous facilities and patterns that the .NET framework supplies to simplify the code and reduce resource use.

Here are the underlying structures in .NET that I know of:

• Threads
• ThreadPools
• Tasks

The following are the patterns used:

• Asynchrounous Programming Model (APM) -- Difficult to implement. Basically obsoleted.
• Event Asynchronous Pattern (EAP) -- Easy to implement. Consuming the pattern creates spagettified code that is just one nested callback after another.
• Task-based Asynchronous Pattern (TAP) -- Easy to implement. Extremely easy to use (await/async keywords). Works with the Task class mentioned above.

[ThadHouse]

I actually tried using async and await, but I found it extremely hard to use. Mainly I think it was because the git and ssh libraries don't support native async, so getting those to work like async functions just were not working. For some reason, the awaits would actually not wait, because the async task would never actually start. Maybe I was doing this wrong, but I just could not get it working.

Also, a lot of tools in this repository are just testing ones I've been writing, and designed to run on a PC anyway. So a little bit of extra resources shouldn't be a big deal.

However, on the RoboRIO side performance is essential. But most of the threads there are not short threads, but are indefinitely running threads. I think the only pool based threads are already using thread pools. All the other ones, like the network tables and driver station loops run forever anyway, so they should be threads, at least I think.

[jkoritzinsky]

Every time I've used async/await it's been super easy, but it makes sense that it depends on which libraries you're using. We should at least be using ThreadPools on the user side. We don't need this level of threading and we don't need this amount of control over the methods. Additionally, we should not be more resource intensive than we need to be just because we can.

I already did a sweep on the WPILib project and switched the ones that should be threadpooled over to the ThreadPool.

[ThadHouse]

As of right now, the only user side code is over in the FRC Extension repository. That could be switched over to a thread pool, but since reading around it looks like thread pools are limited to 25 per cpu per applicaiton, and that code runs inside of VS, would we run into pool issues inside of visual studio?

EDIT: Looking through some documentation, it looks like thread pool is not recommended for threads that block for extend periods of time. I know most of the ones connecting to the RIO each block for 5-10 seconds while trying to actually connect. Would that be considered extended?

[ThadHouse]

I guess the RoboRIO tool in here is used by that, but it still could run into the same issue as above, while running inside of visual studio.

[jkoritzinsky]

For the tools that run inside of Visual Studio, we should use Tasks because their underlying scheduler, the TaskScheduler class, will schedule on the SynchronizationContext that Visual Studio uses. We'll be fine. Also, we should look at our design and see if we really need as much asynchrony as we have. Also, scheduling on the ThreadPool just queues the method, it doesn't create a new thread. Using ThreadPool directly would also work.

[ThadHouse]

In VS the entire deploy loops has to be run in its own task or thread. If not, it blocks the entire VS windows for the 20+ seconds it deploys, which is unacceptable. Right now its a thread, but if a task would be better we should switch to that.

[jkoritzinsky]

I'll take a stab at fixing up the deploy scripts.