improvement request: refactoring the current Arduino libs and cores (esp. ARM, ARMD, STM32) to make them multithreading-safe

[shiftleftplusone]

improvement request: as already stated by M. Patel and P. Stoffregen in https://github.com/arduino/Arduino/issues/5914 there is an urgent need of refactoring the current Arduino libs and cores (especially for ARM, ARMD, STM32) to make them multithreading-safe.

Having MT-safe cores and libs is indispensible especially for more powerful MCUs , i.e. ARM, ARMD, STM32-cores like e.g., the Zero, M0, Due, Teensy, and the new STAR OTTO.

They all have lot of memory and cpu-power but that can be utilized reasonably only by powerful multilthreading libraries (e.g. std::thread (C++11/14) and even possibly POSIX pthread (ANSI-C) ) which require compellingly reliable thread-safe core and lib fundaments.

[dlabun]

I don't see where in #5914 PaulStoffregen says there's an urgent need for making the libraries multi thread safe... In fact he warns it could cause issues.

[shiftleftplusone]

it's the logical conclusion from what both authors wrote, the crucial statements are:

" In fact, the vast majority use static data or other techniques that will randomly & intermittently fail if accessed from multiple preemptively scheduled threads."

"The Scheduler (pthreads) risks opening a can-of-worms too large to handle. The current Arduino core(s) needs refactoring before this becomes feasible."

So it's undisputed that for MT a refactoring the current Arduino libs and cores is needed, and as a reliably working multithreading as urgently needed, in advance a refactoring especially of the ARM/STM core is urgently needed: because of these issues the initially considered POSIX pthread port to Arduino could not even be started.

This task is in any case sensible and justified, and it is quite ridiculous to question this on this polemical level.

[dlabun]

I was questioning the level of urgency and not the justification. When you throw out the word "polemical" all I can do is shrug my shoulders and go find some other problem to solve.

[PaulStoffregen]

I don't see where in #5914 PaulStoffregen says there's an urgent need for making the libraries multi thread safe...

Indeed, I never said anything like "urgent need" on this subject. Those are @shiftleftplusone's words, not mine!

My general opinion is preemptive multithreading is far too difficult for novice programmers. In fact, it often turns out to be too hard for even very experienced people. Race conditions, deadlocks and other intermittent bugs are easy to make and extremely frustrating to find and fix, or sometimes even just understand. Even on Windows, Linux and Macintosh, multithreaded programs are not the norm. When they are made, often it's on top of higher level platforms (eg, Apple's "Grand Central Dispatch") which aim to impose usage models to prevent difficult race conditions.

[shiftleftplusone]

especially std::thread and pthread are far easier to use than those rough and jolty attempts by using interrupts and ISRs. Even some existing libs could be improved to work more reliable, e.g. for simultaneously running PID controls and for reading keyboard by a background thread to make it stdio.h and cstdio - compatible (getchar, gets, scanf, cin) and work smooth without blocking the other tasks/threads. Especially the keyboard lib is currently working extremely crappy because of this deficiency. Also sensor readings which need delays (e.g., Ultrasonic, 1-Wire) or simply time-consuming procedures (e.g., TFT-output) could be "out-sourced" into autonomously/simultaneously running parallel threads not to block or delay the other threads.

OTOH, to start or to stop or to restart a thread is just 1 line for pthread, which is actually extremely simple, and the ubiquity of std::thread and pthread proven for years or even decades shows that it's reliable, reasonable, and justified.

I actually do not think that it's really required to explain all the advantages of a reliably working multithreading lib, alone the availability of many already existing but non-reliable and unsufficiently working Arduino MT libs and all that cryptic interrupt and ISR stuff show that there is a need to have better alternatives.

Missing that for Arduino would mean to have to drop Arduino completely and migrate to different platforms like Linux SoCs providing full std::thread and pthread capability out of the box.

So having thread-safe cores and libs is no disadvantage, but having to forgo these resources is a serious drawback especially for utilizing powerful ARM Cortex M3/M4 MCUs. Dismissing the need to develop that is simply foolish and short-sighted.

And it's urgent to start the work, because the absence of these conditions has already hindered the development of POSIX-libs portation to Arduino, and because it's surely quite time-consuming to rework the resources: Finally the Star OTTO is now already at the start, but no one is actually supposed to buy such an expensive board (about twice as much as the Raspberry Pi 3) without having reasonable MT available (the same about the Teensys and even the Due).

And that is the reason why I made this improvement request.

[Rotzbua]

@shiftleftplusone And who will refactor the libraries with backwards compatibility? It's easy to make a request, but it's hard to implement.

[shiftleftplusone]

And who will refactor the libraries with backwards compatibility? It's easy to make a request, but it's hard to implement.

no idea who personally, I also have also not designed the POSIX and std::thread libs for gcc UNIX/LINUX, but I am using them just like the majority of gcc programmers for UNIX/LINUX very successfully since a very long time, and of course the libs for UNIX/LINUX are also mostly threadsafe. In case some are not (e.g. some wiringPi GPIO API functions ), one may use mutexes though. Not to mention, that actually also Arduino is gcc (g++)-based.

Anyway, the current situation is not satifactory and not acceptable. Finally the fact that this diligence has not been exercised so far, is no reason to completely abandon that task - instead we still are stuck to shaky Arduino libs and cores, and all that mess already hindered the development of POSIX-libs portation to Arduino which is really embarrassing, tbh.

The justification and reasonibilty of this request has even stated by P. Stoffregen + M.Patel, the only divergence is the level of urgency when to have started with the rework which is now essential. Why I consider it to be VERY urgent I have already widely explained.

[Rotzbua]

The arduino community wants as much backwards compatibility as much as possible. I asked you about plans/experience to provide this. Also you mentioned some techniques to fix the incompatibility of the giop writing/reading functions. Do you have any code? Can you make an pull request to improve the existing libraries or share your fixed libraries?

@shiftleftplusone You never contributed code to a repo on github and call me a troll, thanks for nothing.

[facchinm]

Let's keep calm.

@shiftleftplusone editing a post to add insults is a very trolly behaviour (and the troll is you).

PaulS never said such things, you are saying them; if you don't have enough "power" to convince other people but you have to put your words in other people's mouth, well, probably your ideas are not so convincing.

We try hard to keep this place a nice place of constructive discussion, try not to destroy it (hint: I'm removing the trolling part but leaving the thread open, next bad move and I'll close and lock it, thanks for your understanding :smile: )

[shiftleftplusone]

do what you want, I don't care if you don't see the need to improve Arduino by reworking the cores and libs. It's not my job to care about backwards-compatibility and failsafe, thread-safe libs - it's the Arduino developer's job, and the backwards-compatibility is actually just a part of this whole task. And if M. Patel starts to design a project idea and then immediately abandons it because

"The Scheduler (pthreads) risks opening a can-of-worms too large to handle. The current Arduino core(s) needs refactoring before this becomes feasible."

• what would be a better reason than that to call this task URGENT ??

So who does the Rotzbua (in German == Troll) think he is to question my completely reasonable and justified project request ??

I daresay, if not even the Arduino developers are smart enough to see the need and urgency of my improvement request, then customers will do what we call "voting with the feet" - and Arduino will go down like a lead Zeppelin. (This time this prophecy surely will be fullfilling...)

[dlabun]

Before this issue gets closed and locked, Just have to say it went from pathetic to hilarious because you grossly underestimate how successful Arduino has become and continues to grow.... Oh and you killed any credibility you had with the community.

[PaulStoffregen]

having thread-safe cores and libs is no disadvantage

On 8 bit AVR, static data usually results in smaller and (usually) much faster code. The AVR instruction set has load & store instructions that embed 16 bit RAM addresses directly. Use of pointers (usually) involves considerable overhead, since there are only 3 pairs of registers which can act as pointers and 1 is (usually) dedicated to the stack/frame pointer. Results can vary, but often use of non-static data forces the compiler into quite a register shuffling dance, resulting in larger & slower code.

The smaller and very popular 8 bit boards like Arduino Uno & Nano have very little memory to be spread between many popular libraries. Substantially increasing their memory usage will not be well liked by much of the Arduino world.

Of course, the trade-offs are very different for ARM-based boards like Arduino Zero & Due.

[shiftleftplusone]

@ dlabun: I don't need your or anyone's credibility if people are too dumb to understand what is needed to make libs and cores work reliably. Do what you want, Rasperry Pi has already now selled more units than Arduino, and the Pis are half the price of what a far less powerful Otto will cost. So understand or not and then go down.

[shiftleftplusone]

@ P. Stoffregen: I am not talking at all about those rediculous 8bit cores but about 32-bit Dues, Zeros, Teensys, and the Star Otto - I stated that already. Struggle with Intr and ISR on the AVrs and be lucky with it - or at least with the Scheduler lib.

[PaulStoffregen]

Arduino is so successful, where so many others were not, because of attention paid to human factors.

[shiftleftplusone]

@ P Stoffregen: surely Hernando Barragán was completely right with his master's thesis objectives about Wiring, but the ancient implementations for AVRs since 2003 have to be improved for more powerful MCUs ( ARM32/STM32) which are neglected in a big way.

OTOH, at least Python is also very succesful on the Pi because of it's ubiquity, versatility, and user friendliness (that is admittedly not true for C/C++ on the Pi, which eventually is a big chance for Arduino Due, M3 and M4 Teensys, and the Star Otto, provided that the common gcc C/C++ modules and libs will be supported also by the Arduino ARM IDE ).

Probably the libs and cores have to be split far more definitely into 2 independent branches, ie AVR-libs and ARM-libs (which is partially already processed, e.g. for stdio.h functions like vsprintf and floats for sprintf).

I don't actually see why there is a need to argue about this current trapped and desolated situation at all, it's clear to see that the the ARM core platform is extremely neglected and restricted by the Arduino development. Constricting, cramping, and constraining the powerful ARMs to the poor AVR platform environments is like cramming a Ferrari engine into a 1960's Cinquecento chassis: Everyone would recognize at first glance how nonsensical this is in the long run. So please start finally reworking the cores and libs for the ARM-powered bords.

[facchinm]

You are completely underestimating PORTABILITY. A sketch written in 2007 for an Arduino Diecimila (with pure Arduino APIs, no AVR related stuff) still works on a Due, a MKR1000, a Teensy, a 101 etc.

Plus, if you buy an "Arduino" board, you are completely free to replace the "standard" core with a full-fledged RTOS in case you need multitasking (need some links? http://chibios.org/dokuwiki/doku.php https://www.zephyrproject.org/ and so on).

Keep in mind that all the pthread stuff is tightly coupled with the UNIX philosophy, small tools designed to do one single task, so multitasking is a must. The MCU world needs to focus on speed, code density and special purpose.

You CAN run an Arduino sketch as an RTOS task (take a look at the Arduino porting for ESP32) but probably if you interact with the WiFi chip from two thread it's going to crash. Does it mean that the WiFi library must be rewritten to be thread-safe? Or maybe you must rethink your architecture so only a single task interacts with the WiFi chip? Does it make sense to have two tasks accessing different SPI devices instead than a single loop where reads are triggered by interrupts (or polled) ?

Said that, this thread is not going anywhere, so I'm closing it. If you happen to have proposals instead of rants I'll be superhappy to reopen it :smile:

[PaulStoffregen]

Just curious, are you "ArthurD" from the Arduino forums?

[shiftleftplusone]

I simply really would have liked to buy a Star Otto or perhaps even a Cortex M4 driven Teensy, but dispensing with pre-emptive multithreading (either if pthread or an enhanced Scheduler or what ever) it makes no sense at all. For that purpose I also will purchase suitable Shields and hardware add-ons (e.g., Star TFT ,...) - and WT* do I care about 10 years old 2007 stuff?

As I am a consumer and no developer I can't tell you how to do your job. (Same as if I am reporting OS and FW bugs and faults and deficiencies about a Andriod Smartphone, a Windows PC, or a MacBook).

So @ developers: do a better job and construct a more powerful API and IDE for ARM32-cores - or let it be and go down.

So for now I'll drop my decision to invest in new Arduino Star Otto hardware and will only re-think about that if once the standard Arduino API and IDE will have been enhanced by pre-emptive mutithreading libs and modules. FTM it's simply not worth while.

[PaulStoffregen]

Teensy will not meet your requirements. Do not buy a Teensy!

Perhaps Star Otto will be worth the wait? It's being developed by a completely different group of people. Maybe they will take your concerns more seriously?

Here is Star Otto's core library. Maybe open an issue about threading there?

https://github.com/arduino-org/arduino-core-stm32f4

[PaulStoffregen]

FWIW, they appear to be leaning heavily on ST's HAL. Maybe that will give them the ability to do what you want? It's designed for ST's regular customers with large teams of professional engineers who probably do use RTOS systems.

Rumor has it they have some sort of partnership or collaboration directly with ST for Star Otto.

If there were ever a time & opportunity to design in proper critical sections or other features to preemptive threading for a brand new board's core library, this is probably it.

[shiftleftplusone]

I only mentioned the Teensy because the 3.2 is also a Cortex M4 just like the Star Otto as far I have read (so far I falsely assumed the Teensy 3.1 to be driven by a Cortex M3 core, but it's also M4 as it seems, but anyway...) . Of course this topic is motivated by the Star Otto, but of course it's an Arduino and must be maintained by the re-unified Arduino IDE (i.e., 8.1 ++), additionally also the Arduino Due has to be involved for the required changes, too.

It's a general ARM/ARMD/STM32 issue, and so THIS HERE is the right place to initiate a rework of the libs and cores and a pre-emptive MT lib. I also actually doubt that the .org people are capable of reworking current ARM cores and libs at all.

[PaulStoffregen]

All ARM boards (even Due & Zero) are now packages managed by through Arduino's Boards Manager. Arduino.org's M0-Pro board is already integrated into the new unified IDE, but as a package maintained by Arduino.org. Star Otto seems almost certain to be handled the same way.

Arduino.org hired an engineer named Francesco to work on Star Otto. They say they're collaborating with ST. If there were ever a time to consider preemptive threading safety, this is probably it. After they release, changes for thread safety are likely to meet resistance for compatibility concerns.

If there were ever a time to bring this issue up specifically for Star Otto, now is likely the best time!

[shiftleftplusone]

do it, it's not not MY job. And do it also for M0, zero, and above all, the Due as well.

I just now have ordered 2 new Raspberry Pis (1 Pi2 and 1 Pi3) plus 1 Pi cam plus some HATs as I cannot discover the willing of you developers to enhance your fundamental - general - Arduino ARM cores and libs for pre-emptive MT.

[PaulStoffregen]

Why Due above all?

[PaulStoffregen]

Sure seems you feel strongly enough about multithreading to rant & antagonize people here, who've said they don't intend to do what you want, but not enough to initiate dialogue with the Arduino.org folks who are developing what will soon be the most powerful Arduino microcontroller board.

Maybe this isn't really about multithreading at all?

[dlabun]

Just a troll Paul, Calling himself a consumer and not developer yet he's complain about multi threading.... Your average Arduino user probably has no idea what multithreading is

[PaulStoffregen]

Yeah, I'm pretty sure he's ArthurD from the forums.

[shiftleftplusone]

Due above all, because I have one (and the Due is finally already available opposite to the Start Otto) -- but multithreading does not run reliably and threads cannot be terminated prematurely by the 2 available Due Scheduler libs, and on different platforms other than the Due (e.g., the the Mega) there are too many MT issues (see different topic, it always crashes) . Star Otto, because it has even more power and more RAM and has audio and SD on board with the capability to plug a standard USB keyboard which has (hopefully) drivers to read key strokes, opposite to what is available for Arduinos currently at all - but it was still not available yet. But I am not supposed to do the developer's work, and I have no C++ programming skills at all, just ANSI C, nonetheless I use MT already since >5 years (POSIX pthread and the restricted Arduino Scheduler stuff)). If not even the Arduino developers and contributors like you and M. Patel see the need to establish MT-safe libs and cores and torpedo all these requests then I can just shrug my shoulders. And who the f*** is ArthurD ?

ps, MT meanwhile runs fine and smooth by pthread on my new quadcore Raspis, BTW, and I also found C libs to work with the Pi HATs. I will use them for my future projects instead of Arduinos and will now use Arduinos only for slave board purposes (e.g., IO muxers to the Raspis)