add c++ std::thread wrapper layer

[mahyar1284]

No description provided.

[richard-damon]

The biggest issue with the std::thread class is that the constructor doesn't provide the needed information to create a FreeRTOS thread. There is no way to specify anything like a priority or a stack side.

It might be possible another project, but this project is designed to be a thin wrapper that keeps most of the features of FreeRTOS available. std::thread is designed to be a least common denominator interface.

[alfred-ai]

We can overload std::thread, but that is more like an exercise for whoever wants to bring in more std primitives (e.g. std::mutex).

I believe the biggest challenge is to implement std::thread::join() (for those who do run-time task destruction), because that will likely require some kind of messaging/signalling operations, or even writing a FreeRTOS daemon.

[mahyar1284]

I believe the biggest challenge is to implement std::thread::join() (for those who do run-time task destruction), because that will likely require some kind of messaging/signalling operations, or even writing a FreeRTOS daemon.

is it possible or it's too hard to implement std::thread::join()?

[richard-damon]

It isn't impossible, but it would be in no way trivial. First, it would require adding a semaphore to the Task object that gets set when the task ends (so join doesn't need to go into a polling loop). Next you would need to somehow implement a link from the actual FreeRTOS TCB to the Task structure, and use one of the trace hooks so that on the termination of the task, that semaphore actually gets set.

Also, std::thread could only represent a dynamic memory created task, not a static task, at least not with the same method that my Task class uses, as the Task class in not move constructable, since the TCB and stack for static allocated classes is in the object, and that isn't movable. An implemetation of std::thread would need to have just a pointer to a Task class or a task handle in it, to allow the move.