Add and use a task_create API

[peterbarker]

Recently we started to get thread-stuck in our CI:

2021-03-17T16:41:37.2038424Z AT-0161.0: AP: AP_Logger: stuck thread (write)

causing random failures.

This is probably due to moving the IO thread to being an actual thread (#16117). As an IO process in SITL the write() would've block in the main thread - but now it blocks in its own thread so the heartbeat isn't updated and we end up considering it stuck.

This new API is very similar to the thread_create API, except that it takes three functors - one for initialisation code, one for the body of the thread's loop and one for the delay to be used after the thread body is done.

This allows SITL to run the body of the task in the same way that the timer-proc and io-proc thread bodies are run by the scheduler - synchronously in the main loop as part of SITL scheduling. AP_HAL_ChibiOS creates a thread, and calls init(), then loops across calling the body and delaying according to the result of the get_delay_us call.

Moving to this method should ease debugging of thread-related things in SITL (in particular, the thread used by AC_Avoidance is difficult to work with in SITL). Some work on the abstraction might permit us to create some sort of task-group to consolidate some of the code around the io-proc and timer-proc facilities.

This has been lightly tested in SITL and on a Pixhawk4-Mini.

[tridge]

needs this a comment explaining usage

[peterbarker]

Fixed.

[tridge]

comment explaining the delay

[peterbarker]

Done

[tridge]

needs comments

[peterbarker]

Added comment and renamed to calculate_thread_priority

[peterbarker]

I've created a simpler, crappier, less-complete fix in #16978

[peterbarker]

It's not free, being an alternative infrastructure to the existing thread_create method. I don't think this can't do anything the existing method can, however, so we could move entirely to this mechanism

Board               AP_Periph  blimp  bootloader  copter  heli  iofirmware  plane  rover  sub
Durandal                       240    *           248     256               424    256    288
HerePro             152                                                                   
Hitec-Airspeed      152                                                                   
KakuteH7-bdshot                136    *           144     112               48     184    128
MatekF405                      208    *           176     168               136    160    144
Pixhawk1-1M-bdshot             160                200     184               184    176    136
f103-QiotekPeriph   152                                                                   
f303-Universal      152                                                                   
iomcu                                                           152                       
revo-mini                      144    *           136     144               -16    128    136
skyviper-v2450                                    160                                     

[andyp1per]

You could add a destructor to this to clean up the two members and then use new and delete in the usage - might make it slightly cleaner

[peterbarker]

You could add a destructor to this to clean up the two members and then use new and delete in the usage - might make it slightly cleaner

If I'm understanding your suggestion correctly that would involve moving doing this allocation into the constructor for struct task_ctx here?

Couldn't quite do that as you can't fail in a constructor. But I've pushed some patches on top which add an initialise method, and yes, I think it is an improvement, thanks!

[peterbarker]

.... I've now removed the calls to malloc in here. I've no idea what I was thinking when I added those, but it seems to get by with just having the init/body procs as members of the context.

I've done a smoke-test on a CubeOrange here and it seems to do logging just fine-and-dandy.