Feature request: Support for C and C++ threads

[franzhollerer-Artesyn]

Your CMSIS-RTOS documentation states:

The CMSIS-RTOS API is a generic RTOS interface for ARM® Cortex®-M processor-based devices. CMSIS-RTOS provides a standardized API for software components that require RTOS functionality and gives therefore serious benefits to the users and the software industry.

• CMSIS-RTOS provides basic features that are required in many applications or technologies such as UML or Java (JVM).
• The unified feature set of the CMSIS-RTOS API simplifies sharing of software components and reduces learning efforts.
• Middleware components that use the CMSIS-RTOS API are RTOS agnostic. CMSIS-RTOS compliant middleware is easier to adapt.
• Standard project templates (such as motor control) of the CMSIS-RTOS API may be shipped with freely available CMSIS-RTOS implementations.

I agree with the intention of the generic RTOS interface, but I personally would suggest a different approach.

As you know the C11x and the C++11 standard specify thread support, more or less in compliance with and derived from POSIX pthread.

http://www.stroustrup.com/C++11FAQ.html#std-threads https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

I would prefer support for threads at language level as proposed by the C11x and C++11 standard. CMSIS could provided the required runtime environment to support C11x and C++11 threads, rather than proposing its own threading system.

I am aware that the C11x and C++11 features must be extended by functions which allow to signal something to threads from interrupt context, i.e. a way to wake a thread from an interrupt. But in general I think it would be very beneficial if the engineering effort goes into the compiler and its runtime environment to support multithreading at language level as supposed by the standard.

Is there any plan to support Cx11 and C++ threads in future?

[ilg-ul]

any plan to support Cx11 and C++ threads in future?

the CMSIS++ proposal, that was intended to push ARM to redesign CMSIS RTOS closer to the standards (ISO and POSIX), already includes fully functional ISO C++11 threads support:

http://micro-os-plus.github.io/reference/cmsis-plus/group__cmsis-plus-iso.html

however, from my experience implementing these functions, they seem designed more as an additional layer on top of POSIX Threads and less as a full API in itself, since very few details are available in the top classes.

[franzhollerer-Artesyn]

That sounds interesting. And thank you for the link. I was not aware of it.

[franzhollerer-Artesyn]

http://micro-os-plus.github.io/reference/cmsis-plus/group__cmsis-plus-iso.html

Is there also some information available which methods / functions will be allowed to be called within an interrupt service routine?

[ilg-ul]

which methods / functions will be allowed to be called within an interrupt service routine?

oops! this information is available only in the main RTOS API pages, for the ISO API... I forgot to add it. :-( (added on my TODO list).

but, taking a quick look at the API, there are three classes: thread, mutex and systick_clock. none of them seem available from ISRs. as for the functions, those in the this_thread obviously do not apply to ISRs.

[JonatanAntoni]

We have this in our backlog, and Liviu is already heading this direction. I think we have to be very careful regarding very limited resources on devices CMSIS is mainly aimed for. For signaling threads from ISR we currently stick to well known RTOS paradigms like mutexes/semaphores, mailboxes, signals/flags and events.

[ilg-ul]

I think POSIX signals deal with different things, and I'm also not yet convinced that a light implementation for embedded usage is realistic/useful, so I did not add one to CMSIS++; but when I designed my APIs I did some research, and this is still on my TODO list.

As for signalling threads from ISR, at the scheduler level there is only one important function, os::rtos::thread::resume() that can also be invoked from ISR, since it is the building block of all synchronisation objects, and semaphores, memory pools, message queues and event flags (not mutexes!) have functions that can be invoked from ISRs.

[franzhollerer-Artesyn]

One more question. The project page http://micro-os-plus.github.io/reference/cmsis-plus/group__cmsis-plus-iso.html looks very interesting. I think its heading in the right direction.

Is this a project driven by ARM/Keil, this means will it be part of a future CMSIS standard, or is this a private open source project?

What is the personal relationship between Liviu and ARM/Keil?

[franzhollerer-Artesyn]

To my understanding threads or not only a question of library / runtime support. Especially when the hardware gets more complex, and have several cores interacting with each other. The programming language itself must have an understanding of concurrency.

I read an very interesting article about this problem years ago:

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

Is the development of the CMSIS eco system (this means including the compilers) going in this direction?

[JonatanAntoni]

@franzhollerer-Artesyn we are currently working on what we called CMSIS-Zone, refer to the slides from Embedded World. At the moment I am still focused on single core controllers. But we have also multi core devices (AMP/HMP, but no SMP yet) in mind. Thank you for that reference. We have a lot of work to do and it will need its time.

If you can provide us real world examples you would like to have tool/library support for this might help us.

The CMSIS++ project is driven by Liviu not by ARM/Keil. We are in ongoing discussions which ideas we can integrate with CMSIS. CMSIS is heavily used by ARM partners and ecosystem thus we are very constrained regarding changes we like to introduce. In order to get new ideas proven it might be easier to develop stuff outside CMSIS in a first step. Please don't get discouraged if we appear very conservative on integrating enhancements.

[franzhollerer-Artesyn]

If you can provide us real world examples you would like to have tool/library support for this might help us.

Actually, I have no real world example at the moment. It's just a nice to have consideration from my side. The point is that both C11x and C++11 address concurrency and thread support at language level.

In my humble opinion it would be a nice approach to provide these language features native, as very efficient and highly optimized thread support at compiler toolchain level, and provide the more advanced RTOS features on top of it - Instead of doing the other way round: implementing C11x and C++11 threads as wrapper to RTX or FreeRTOS.

The C++11 threads could serve as reference even beyond ARM Cortex based MCUs.

[ilg-ul]

to provide these language features native, as very efficient and highly optimized thread support at compiler toolchain level, and provide the more advanced RTOS features on top of it

this is not realistic, the compiler support for threads is zero, everything is done in the libraries.

by design ISO C/C++ threads are wrappers over native threads, the API has functions to return a handler to the native implementation, in case you want to do anything with the thread.

same for mutex.

since I already fully implemented C++11 threads in CMSIS++, I can tell you that except some educational purposes, I personally do not plan to use them in practical applications, for several reasons:

• they always use dynamic memory, the C++ object needs to create a new native thread object; there can be no static C++ threads (in CMSIS++, by design, all objects have variants that use statically allocated memory)
• they do not allow the use of custom allocators, so if you want to allocate the stack from a pool, and the TCBs from another, it is not possible (in CMSIS++, by design, all objects have custom allocators, with defaults for system vs user areas)
• they do not allow to set object names, so thread aware debugging will not distinguish between threads (in CMSIS++ all objects have names, intended to help during debugging)

on the Cons side:

• they are very nice and easy to use,
• they have variable number of arguments
• they are standard (or they should be...)

[franzhollerer-Artesyn]

Thank you for the very interesting insight.

this is not realistic, the compiler support for threads is zero, everything is done in the libraries.

Sorry for my sloppy wording. This is why I have written compiler toolchain, considering not only the compiler in the narrow sense but also the libraries around it.