C++ async und futures auf µC verwenden

Oliver S. schrieb:
> wird der overhead gegenüber einer „zu Fuß“ programmierten Lösung
> nahezu Null

Benötigen std::futures nicht dynamischen Speicher und exceptions?

ich finde da die asynchrone Programmierung mit EventQueues interessant, 
also eher um viele threads zu vermeiden. Das geht auch ohne die Libs, 
aber mit Unterstützung der Sprache sollte das übersichtlicher werden.
In Javascript war async vielleicht nicht Vorreiter, ist damit aber sehr 
populär geworden. Threads brauchen viel Speicher durch eigene Stacks je 
Tasks, da sehe ich auf µC bei EventQueues Vorteile. Zumindest wenn in 
einem Thread Aufgaben kooperativ abgearbeitet werden. µC haben ja auch 
nur einen Kern um Aufgaben zu erledigen, von Konstrukten wie M7+M0 oder 
ähnlichen mal abgesehen.

mbed-os5, habe ich hier noch nicht genug damit genervt? :)

Ich habe gesehen das es da in Tests verwendet wird, zB hier:
https://github.com/ARMmbed/mbed-os/blob/ffdd54315f98bda6021fec9076d271571dbe32e3/UNITTESTS/features/netsocket/InternetSocket/test_InternetSocket.cpp#L157

Vincent H. schrieb:
> Das is ein x86 Test...
>
> /edit
> Blöd formuliert. Was ich mein is das is ein Host-Test. Der läuft nicht
> am Target.

nope, das ist ein Test für das Target mit Cortex-M irgendwas.

Und der Code im Anhang läuft, warum sollte er auch nicht? Die Newlib und 
std sind für Cortex-M implementiert. Sogar ein cout<< "hello"; 
funktioniert, ist dann aber mit +200 kB doch etwas viel des Guten.

1

Hello from BLACKPILL_F411CE

2

Mbed OS version: 99.99.99

3

test Future

4

start doSomethingElse

5

doSomethingElse done

6

diff: 4.000000

Was noch nicht geklappt hat ist der async call, da haut mir der Compiler 
Fehlermeldungen um die Ohren die ich noch nie gesehen habe. Die Zeilen 
hatte ich von Stackoverflow zusammengekratzt. Was ist da an dem 
std::async(std::launch::async, doSomething); faul? Irgendwas von 
incomplete type bemängelt der Compiler.

1

[Error] d:\Projects\Sn\LocalGit\test\Mbed5-Projects\apps\testFuture\source\main.cpp:36:58: invalid use of incomplete type 'class std::future<void>'

2

[ERROR] d:\Projects\Sn\LocalGit\test\Mbed5-Projects\apps\testFuture\source\main.cpp: In function 'int main()':

3

d:\Projects\Sn\LocalGit\test\Mbed5-Projects\apps\testFuture\source\main.cpp:36:58: error: invalid use of incomplete type 'class std::future<void>' 

4

   36 |     auto fut = std::async(std::launch::async, doSomething);

5

      |                                                          ^

6

In file included from d:\Projects\Sn\LocalGit\test\Mbed5-Projects\apps\testFuture\source\main.cpp:3:

7

c:\program files (x86)\gnu tools arm embedded\9 2019-q4-major\arm-none-eabi\include\c++\9.2.1\future:125:11: note: declaration of 'class std::future<void>'      

8

  125 |     class future;

9

      |           ^~~~~~

Oliver S. schrieb:
> Laut Beachreibung laufen die Unittests nicht auf dem Target, sondern
> nativ auf dem Host (Windows, Linux, Apple).

da hst du Recht, ich habe das mit den greentea tests verwechselt, die 
laufen auf dem Target.

Das kann dann erklären warum futue nicht komplett ist, der header ist ja 
eingebunden.
Schade, ist die Zukunft doch nicht auf dem µC angekommen?

der g++ meldet mit -v unter anderem 'Thread model: single' und 
'configured with: --disable-threads'. Hat also definitiv keine 
Unterstützung dafür. Ok, das ist OS abhängig aber ein printf kann man ja 
auch umleiten.

Der ARMC6 redet etwas mehr Klartext:

1

[Error] thread@114,2: <thread> is not supported on this single threaded system

2

[Error] future@378,2: <future> is not supported on this single threaded system

Mal sehen wieviele Jahre es dauert bis <future> auf dem µC möglich ist 
:)