Gast
#6096888
macht hier jemand schon so etwas? Ist der Overhead der std da sehr hoch oder ist das praktikabel? Natürlich nicht auf einem ATTiny, sondern Cortex-M die einiges an Flash und RAM mitbringen.
Wenn du eh schon ein zu den C++-Standardlibs kompatibles Multithreading-OS drauf laufen hast (da setzt die C++-Standardlib drauf auf), wird der overhead gegenüber einer „zu Fuß“ programmierten Lösung nahezu Null (und gegenüber dem Rest eh vernachlässigbar) sein. Oliver
Gast
#6096931
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?
Nun ja, keine Arme, keine Kekse... Aus irgend einem guten Grund wird man ja std::futures verwenden wollen. Wenn man nur mal ein Thread starten will, braucht man das nicht. Oliver
Gast
#6096957
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.
Johannes S. schrieb: > macht hier jemand schon so etwas? Ist der Overhead der std da sehr hoch > oder ist das praktikabel? Natürlich nicht auf einem ATTiny, sondern > Cortex-M die einiges an Flash und RAM mitbringen. Das ist erst einmal die Frage nach dem OS, was Du einsetzt / einsetzen möchtest.
Gast
#6096982
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
In dem Fall schreib dir halt mal ein minimales Testprogramm, und schau dir an, was der Compiler draus macht. Oliver
Nachtrag: Und berichte, was rausgekommen ist ... Oliver
Das is ein x86 Test... /edit Blöd formuliert. Was ich mein is das is ein Host-Test. Der läuft nicht am Target.
Verrat doch nicht alles ;) Versuch macht kluch... Oliver
Gast
#6097170
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Johannes S. schrieb: > invalid use of incomplete type 'class std::future<void>' Sagt genau das aus, was es aussagt: An der relevanten Stelle braucht der Compiler die vollständige Klasse, kennt die aber nicht, sondern (vermutlich) nur eine Vorwärtsdeklaration davon. Üblicherweise fehlt da ein include, in dem Fall wäre das <future>, warum auch immer. Johannes S. schrieb: > nope, das ist ein Test für das Target mit Cortex-M irgendwas. Laut Beachreibung laufen die Unittests nicht auf dem Target, sondern nativ auf dem Host (Windows, Linux, Apple). Oliver
Gast
#6097199
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?
Gast
#6097316
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 | |
2 | |
Mal sehen wieviele Jahre es dauert bis <future> auf dem µC möglich ist :)
Läuft doch schon, nur vermutlich halt single-threaded ;) Johannes S. schrieb: > > Hello from BLACKPILL_F411CE > Mbed OS version: 99.99.99 > test Future > start doSomethingElse > doSomethingElse done > diff: 4.000000 Oliver