Connect with us

Künstliche Intelligenz

Asynchrone Programmierung – Teil 1: C++ komfortabel mit Boost.Asio


Mit Boost.Asio gibt es eine altbekannte und dennoch moderne, effiziente und mächtige Bibliothek für die asynchrone Programmierung in C++. Je nach C++-Version können Entwicklerinnen und Entwickler damit auf verschiedene Arten asynchron programmieren, ohne dabei auf komplizierte und fehleranfällige Threading-Mechanismen zurückgreifen zu müssen.


Martin Meeser

Martin Meeser

Martin Meeser ist selbständiger Diplominformatiker (Uni) und bietet Dienstleistungen zum Thema Softwareentwicklung an: Individual-Software-Entwicklung, Beratung zu Prozessen und Schulungen. In zahlreichen Projekten betreute er bisher Kunden unter anderem aus den Bereichen Automotive, Finance, Raumfahrt, Radioastronomie und Medizintechnik.

Dieser Artikel bildet den Auftakt einer Reihe zur asynchronen Programmierung in verschiedenen Sprachen – außer Python, das vor Kurzem erst vorgestellt wurde.

Einbinden von Boost.Asio

Auf Linux-Systemen kann man Boost in einer aktuellen Version über die diversen Paketverwaltungen beziehen, unter Ubuntu ist das beispielsweise mit apitude aktuell die Version 1.83:

sudo apt-get install libboost-all-dev

Möchte man die neueste Version (aktuell 1.89) einsetzen oder arbeitet unter Windows, lädt man Boost von der Homepage und baut es selbst. Die entsprechenden Anleitungen finden sich beim Anbieter. Es gibt auch eine baugleiche, reine Asio-Bibliothek – ohne Boost-Abhängigkeiten und mit einem anderen Namespace, die hier aber nicht betrachtet wird.

Context und Event Loop

Grundsätzlich erfordert asynchrone Programmierung ein verwaltendes System, das die API sowie die Mechanismen bereitstellt und den Programmablauf orchestriert. Hier hat sich allgemein der Begriff „Event Loop“ etabliert, Boost.Asio spricht jedoch von „Context“. Der geläufige Ansatz ist es, einen io_context zu verwenden, wie folgendes Beispiel zeigt:


#include 
#include 

int main()
{
    boost::asio::io_context io_context;
    boost::asio::post(io_context, []()
    {
        std::cout << "Hello World from async context!" << std::endl;
    });

    // async execution startet nach dem Aufruf von io_context.run()
    io_context.run(); // run() blockiert bis keine Arbeit mehr vorliegt
}


Listing 1: Einfaches Beispiel zur Verwendung eines Kontextes

post() reiht das Funktionsobjekt, das als Parameter übergeben wird – hier ein Lambda – in die Warteschlange des Kontexts ein und springt sofort zurück.

Der Kontext startet durch den Aufruf von io_context.run() und beginnt nun, die Funktionen der Reihe nach abzuarbeiten. In dem Beispiel wird „Hello World…“ also erst nach io_context.run() ausgegeben.

So initialisiert man das Programm, ohne dass asynchrone Mechanismen auf ein nicht fertig initialisiertes System einwirken. Das vermeidet Fehler, die unter bestimmten Umständen auftreten und schwer zu finden sind, beispielsweise zufällige Nachrichten aus einem anderen Prozess oder eine hohe Auslastung der CPU durch ein anderes Programm.

Die Methode io_context.run() endet, sobald keine Aufgaben mehr vorhanden sind oder io_context.stop() aufgerufen wird. io_context.run() kann man nur einmal pro Thread verwenden. Es ist aber möglich, run() mit dem gleichen io_context aus mehreren Threads aufzurufen.

Im Fall von Listing 1 übergibt der io_context die Arbeit einem Thread, was eine nebenläufige (concurrent) Ausführung bedeutet. In Listing 2 wird io_context.run() von mehreren Threads aus aufgerufen. Übergibt man nun Aufgaben an den Kontext, dann führt dieser die Aufgaben sofort auf einem der Threads aus. Diese Ausführung ist wirklich parallel. Sind alle Threads bereits mit Arbeit ausgelastet, wird die neue Aufgabe in eine Warteschlange eingereiht. Sobald einer der Threads seine Aufgabe abgeschlossen hat, teilt Context ihm Arbeit aus der Warteschlange zu.


#include 
#include 
#include 
#include 

int main()
{
    boost::asio::io_context io_context;

    int n = 4;
    std::vector<:thread> threads(n);
    for (int i = 0; i < n; i++)
    {
        threads[i] = std::thread([&io_context](){ io_context.run();});
    }

    // ... parallel asynchrone Aktionen hier

    for (auto& t : threads)
    {
        if (t.joinable()){ t.join(); }
    }
}


Listing 2: Verwendung von mehreren Threads in einem io_context

Hier erahnt man bereits die Stärke des asynchronen Programmierstils: Die ausführenden Einheiten sind abgelöst von einem konkreten Thread. Asynchrone Programme skalieren nativ und nutzen so viele Ressourcen, wie zur Verfügung stehen.

Nach meiner Erfahrung ist in der Regel ein Thread völlig ausreichend, während mehrere Threads vor allem bei Serversystemen oder ganz speziellen Aufgaben interessant sind, beispielweise zur Berechnung großer Primzahlen oder anderer algorithmischer Probleme. Je mehr Threads (bzw. CPU-Kerne) dem Kontext zur Verfügung stehen, desto mehr Teil-Berechnungen können parallel erfolgen – ohne jede Veränderung des Programms. Entwickler können sich vollständig auf die Funktionalität konzentrieren.

Es ist möglich, das Verhalten von io_context.run() zu verändern, indem man einen work_guard verwendet, wie in Listing 3 zu sehen ist.


#include 
#include 

int main()
{
    boost::asio::io_context io_context;
    boost::asio::executor_work_guard<:asio::io_context::executor_type>
    work_guard(io_context.get_executor());

    boost::asio::post(io_context, []()
    {
        std::cout << "Hello World from async context." << std::endl;
    });

    boost::asio::signal_set signals(io_context, SIGINT, SIGTERM);
    signals.async_wait([&io_context /*&work_guard*/]
        (const boost::system::error_code& ec, int signal)
        {
            io_context.stop(); // bricht sofort alles ab
            // work_guard.reset(); // bricht ab, wenn alles fertig ist
        });

    io_context.run();
}


Listing 3: executor_work_guard kann verhindern, dass run() zurückspringt, wenn context keine Arbeit mehr hat.

Nun springt io_context.run() erst dann zurück, wenn zum einen io_context.stop() aufgerufen wurde – in diesem Fall kommen bereits vorgesehene Aufgaben nicht mehr zur Ausführung und gerade laufende werden mit einem Abbruch-Fehler gestoppt. Zum anderen springt die Funktion zurück, wenn work_guard.reset() aufgerufen wurde – dann arbeitet das Programm alle gerade laufenden und auch alle vorgesehenen Aufgaben noch ab.

Bei letzterem sollten Entwicklerinnen und Entwickler darauf achten, dass sie innerhalb der eingereihten Einheiten keine neuen Aufgaben hinzufügen – denn sonst gerät der Code in eine asynchrone Endlosschleife und io_context.run() wird niemals enden.

Es gibt noch zwei weitere Kontexte in Boost.Asio: thread_pool (siehe Listing 4) und system_context (siehe Listing 5).


#include 
#include 

int main()
{
    boost::asio::thread_pool thread_pool(16);
    boost::asio::post(thread_pool, []()
    {
        std::cout << "Hello World from async context!" << std::endl;
    });

    // thread_pool.stop(); // bricht alle Arbeit im Pool sofort ab
    thread_pool.join(); // wartet bis alle Arbeit abgeschlossen ist


Listing 4: Beispielhafte Verwendung eines thread_pool

Der thread_pool ist eine einfache und empfohlene Alternative, wenn Entwickler mehrere Threads verwenden möchten und keine feingranulare Steuerung der einzelnen Threads benötigen. Eines muss man jedoch berücksichtigen: Im Gegensatz zum io_context startet thread_pool direkt nach der Konstruktion. Ansonsten verhält es sich analog zum io_context: Mit der Methode thread_pool.stop() brechen Entwickler die Ausführung sofort ab, mit thread_pool.join() beendet das Programm aber noch alle Aufgaben. Wurde vorher stop() aufgerufen, dann springt join() sofort zurück.

Der system_context ist von überall immer verfügbar – er muss nicht gestartet oder gestoppt werden. Er ist eine gute Wahl, wenn Entwickler an einem bestimmten Punkt ohne großen Aufwand und Vorbereitung – aber auch ohne eigene Steuerung – asynchrone Operationen ausführen möchten.


#include 
#include 

int main()
{
    boost::asio::system_context system_context;
    boost::asio::post(system_context, []()
    {
        std::cout << "Hello World from async context!" << std::endl;
    });
}


Listing 5: Beispielhafte Verwendung von system_context



Source link

Verwandte Themen:
Weiterlesen

Künstliche Intelligenz

software-architektur.tv: DiversIT(y) – Diversität in der IT


Wie erleben Menschen, die in der IT unterrepräsentiert sind, ihren Arbeitsalltag wirklich? In diesem Livestream bringen Liam Bergh, Sabine Wojcieszak und Eberhard Wolff ungefilterte Stimmen direkt auf die Bühne der IT-Tage.

Weiterlesen nach der Anzeige

Im Vorfeld haben sie persönliche Erfahrungsberichte gesammelt – von Mikroaggressionen im Team-Meeting bis zu strukturellen Hürden beim Karrierestart. Diese anonymisierten Geschichten lesen sie vor und diskutieren gemeinsam: Was läuft schief? Was funktioniert bereits gut? Und vor allem: Was kannst du selbst, dein Team oder deine Organisation morgen konkret anders machen?

Aus der Praxis für die Praxis: Diese Session richtet sich an alle, die Diversität nicht nur als HR-Thema verstehen, sondern als strategischen Erfolgsfaktor für ihre IT-Organisation. Ob CTO, Teamlead oder Entwickler:in – hier erhältst du ungefilterte Einblicke aus dem Projektalltag, die sonst oft unsichtbar bleiben, und kannst konkrete Impulse direkt in deinen Alltag mitnehmen.

Was du mitnimmst: Echte Erfahrungen statt Theorie, Verständnis für Barrieren im IT-Alltag und Handlungsfelder für inklusive Teams – so konkret wie möglich, so anonym wie nötig.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 9. Dezember

Die Ausstrahlung findet am Dienstag, 9. Dezember 2025, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

Weiterlesen nach der Anzeige

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.


(mdo)



Source link

Weiterlesen

Künstliche Intelligenz

Vorstellung Mercedes GLB EQ: Im zweiten Anlauf erfolgreich?


Mercedes überrascht mit dem zweiten GLB gleich in doppelter Hinsicht. Zum einen erinnert gerade die hintere Seitenlinie ziemlich an den Smart #5. Zum anderen hält der Konzern am Konzept fest, zwei ähnlich große SUV-Modelle anzubieten. Bisher gab es mit primärem Hinterradantrieb und Wandlerautomatik auf der einen Seite – der des GLC – und primärem Frontantrieb und Doppelkupplungsgetriebe im EQB/GLB Unterschiede, die das Fahren prägten. Das wird mit dem Modellwechsel beseitigt. Der GLB EQ bekommt wie der GLC EQ Hinterradantrieb.

Weiterlesen nach der Anzeige

Der neue GLB wird etwas größer als sein Vorgänger. In der Länge legt er um 4,8 cm auf 4,73 m zu, in der Breite sind es mit 1,86 m 2,7 cm mehr. Der Radstand wächst um 6 cm auf 2,89 m. Standardmäßig ist der GLB ein Fünfsitzer, gegen Aufpreis gibt es zwei weitere Sitze in dritter Reihe. Dann allerdings wird der Kofferraum nicht viel mehr als eine kleine Ablage sein – Mercedes nennt dieses Volumen nicht einmal. Als Fünfsitzer fasst dieser Teil des Gepäckraums 540 Liter im Fünfsitzer. Wer die dritte Reihe bestellt hat, aber gerade nicht nutzt, kann 480 Liter einladen. Bemerkenswert üppig ist mit 127 Litern das Fach unter der vorderen Haube. Auch die maximale Anhängelast ist mit zwei Tonnen großzügig ausgelegt.


Das grundsätzliche Layout ist aus GLC EQ und CLA EQ schon bekannt. (Bild:

Mercedes-Benz

)

Im Innenraum erwartet den Fahrer und seine Gäste das nun schon aus einigen Neuvorstellungen dieses Jahres bekannte Design. Es gibt ein von Bildschirmen dominiertes Armaturenbrett, optional auch mit Beifahrer-Display. Als Betriebssystem dient MB.OS. Eine erste Ausfahrt mit dem CLA EQ zeigte, dass die Sprachsteuerung nochmals verbessert wurde. Es sei allen empfohlen, ihr zumindest eine Chance zu geben, denn sie erleichtert den Zugang wirklich deutlich. Anders als bisher ist ein großes Glasdach serienmäßig, doch es gibt keine Chance mehr, es auch öffnen zu können.

Auch wieder mit Verbrenner

Ursprünglich sollte der Verbrenner mit diesem Modellwechsel Vergangenheit sein, doch während der Entwicklung steuerte Mercedes um. Zusätzlich zu den batterieelektrischen Antrieben, die die Verantwortlichen in den Fokus der Aufmerksamkeit schieben möchten, sind drei Mild-Hybride geplant. Die Leistungsdaten verrät Mercedes für das SUV noch nicht, sie sollen erst im kommenden Jahr kommuniziert werden. Denkbar, ja sogar wahrscheinlich ist ein Angebot wie im CLA, wo die Hybride mit 100, 120 und 140 kW angeboten werden. Anders als im E-Auto ist hier der Frontantrieb der primäre, die Hinterachse wird in dem Allradmodell nur bei Bedarf hinzugeholt. Ein Doppelkupplungsgetriebe mit acht Stufen ist Standard.

Weiterlesen nach der Anzeige

Die Pufferbatterie hat bis zu 1,3 kWh, schreibt Mercedes. Bei sehr geringer Lastanforderung sei sogar elektrisches Fahren möglich. Das ist natürlich bestenfalls Beiwerk, denn im Kern geht es um eine variable Lastpunktverschiebung: Der Verbrenner soll, sooft es eben möglich ist, nahe seines besten Wirkungsgrades arbeiten. Die Einlassventile schließen früher als gewöhnlich, um im sogenannten “Miller-Brennverfahren” eine bessere Nutzung der Expansion zu ermöglichen und damit die Effizienz weiter zu erhöhen. Verbrauchswerte nennt Mercedes noch keine.

Zwei E-Antrieb zum Start des Verkaufs

Ohnehin stehen die drei Mild-Hybride im Schatten der batterieelektrischen Antriebe. Zum Start gibt es ein Heckantriebsmodell (GLB 250+ EQ) mit 200 kW und 335 Nm und ein Allradler, der dem noch einen Elektromotor mit 80 kW an der Vorderachse hinzufügt. Der GLB 350 4Matic kommt damit auf eine Systemleistung von 260 kW und ein maximales Drehmoment von 515 Nm. Viele Hersteller nutzen für den sekundären Antrieb einen Asynchronmotor, der sich ohne Last energieeffizienter mitschleppen lässt, dafür aber andere Nachteile hat. Mercedes verbaut dagegen zwei Synchronmotoren und schreibt sich nebenbei auf die Fahnen, den Anteil schwerer seltener Erden massiv reduziert zu haben.

Langsam, sehr langsam verschiebt sich der Fokus des Interesses bei Elektroautos von der reinen „Und-wie-weit-kommst-du-Debatte“ in eine etwas breitere Betrachtung. Im WLTP nennt Mercedes für den 250+ eine Reichweite zwischen 542 und 631 km, im 350 4Matic sollen es 521 bis 614 km sein. In beiden Fällen ist eine NMC-Batterie (Nickel-Mangan-Cobalt) mit nutzbaren 85 kWh eingebaut. Mercedes macht beim Laden einen riesigen Schritt nach vorn, der manche Bedenken zumindest etwas Wind aus den Segeln nehmen könnte. In der Spitze lädt der GLB mit bis zu 320 kW. Innerhalb von 10 Minuten sollen bis zu 260 km WLTP-Reichweite nachgefüllt sein. Einen Wert für die Aufladung von 10 auf 80 Prozent bleibt die erste Pressemeldung noch schuldig, doch wir gehen davon aus, dass dieser Wert identisch mit dem im CLA EQ sein wird. Dort sind es 22 Minuten. Das wären im Schnitt netto rund 162 kW Ladeleistung.

620 km auf der Autobahn

Eine spekulative Beispielrechnung zur Veranschaulichung: Man startet mit 100 Prozent und fährt die Batterie bis auf 10 Prozent herunter. Das dürften auf der Autobahn, sofern man es nicht auf einen besonders hohen Verbrauch anlegt, mit etwas zusätzlichem Puffer wenigstens rund 350 km sein. Nach der Aufladung auf 80 Prozent kämen wieder etwa 270 km hinzu. Mit einer Pause von 22 Minuten wären somit rund 620 km möglich – wie gesagt, mit etwas Puffer gerechnet. Auch der GLB wird damit nicht jene abholen, die 1000 km ohne jeglichen Stopp absolvieren wollen, aber möglicherweise ein Teil der restlichen Interessenten.


Die hintere Seitenlinie erinnert an den Smart #5. (Bild:

Mercedes-Benz

)

Einschränkungen beim Laden

Zwei Einschränkungen beim Laden gibt es: Wie schon im CLA EQ wird auch der GLB EQ an DC-Ladesäulen mit 400 Volt nur laden können, wenn eine entsprechende Zusatzausstattung geordert wurde. Das trifft zwar nicht auf alle öffentlichen Gleichstromlader zu, kann aber unter Umständen ziemlich unangenehm sein. Hoffentlich hat ein aufmerksamer Programmierer daran gedacht, in GLB-Modellen ohne dieses Extra die inkompatiblen Ladesäulen im Navi auszublenden. Bedenken sollte der Interessent auch, dass serienmäßig nur ein 11-kW-AC-Lader eingebaut ist. Wer an Wechselstrom mit 22 kW laden möchte, muss das ebenfalls ab Werk ordern.

Weniger teuer als der GLC

Vielleicht tröstet es den ein oder anderen, dass der GLB EQ weniger kostet als der GLC EQ. Von preiswert ist dabei selbstverständlich nicht die Rede. Das vorläufige Basismodell ist mit 59.048 Euro angepriesen, der 350er mit 62.178 Euro. Das ist eine überaus selbstbewusste Ansage, denn der GLB-Einstieg liegt damit erheblich oberhalb von Elektroautos wie Skoda Enyaq, BMW iX1 (Test) oder dem Smart #5. Ein Basismodell für etwas weniger Geld soll folgen, doch auch hier sollte sich der Interessent keine übertriebenen Hoffnungen machen: Mit der von den meisten wohl gewählten Ausstattung wird kein GLB EQ wesentlich weniger als 60.000 Euro kosten. Der erste Anlauf von Mercedes in die Welt der Elektromobilität war nicht besonders erfolgreich. Der zweite ist gleichwohl mit einer mutigen Preisgestaltung versehen.

Mehr zur Marke Mercedes


(mfz)



Source link

Weiterlesen

Künstliche Intelligenz

Kfz-Branche erwartet für 2026 rund 700.000 Neuverkäufe von Elektroautos


Der Verband der Automobilindustrie (VDA) und der Zentralverband Deutsches Kraftfahrzeuggewerbe (ZDK) rechnen mit einer Belebung der Verkäufe batterieelektrischer Autos (BEV), bei Plug-in-Hybriden (PHEV) hingegen mit einem Rückgang. Vorläufig soll sich dieser Zuwachs nach den Erwartungen des VDA auf einem Niveau von Gesamtzulassungen noch deutlich unterhalb des Einbruchs der Verkaufszahlen durch Covid-19 abspielen.

Weiterlesen nach der Anzeige

Der VDA erwartet 2026 die Neuzulassung von rund 693.000 neuen BEV in Deutschland, rund 30 Prozent mehr als voraussichtlich 2025 insgesamt. Der Verband der Internationalen Kraftfahrzeughersteller (VDIK) hält es für möglich, dass rund 740.000 BEV neu zugelassen werden. Das wären fast 30 Prozent mehr BEV als im laufenden Jahr und rund ein Viertel aller Neuzulassungen. Inklusive PHEV kommt der VDA in seiner Prognose auf knapp eine Million Neuzulassungen von Fahrzeugen mit Stromspeicher für den Antrieb. Der ZDK ist etwas optimistischer und erwartet sogar 1,1 Millionen Neuverkäufe von BEV und PHEV für 2026. Laut VDA könnten Neuzulassungen von PHEV 2026 um fünf Prozent auf 286.000 leicht sinken.

Die E-Auto-Förderung ist dabei schon einberechnet

Bei den BEV liegt die Prognose des VDA etwas unter der des ZDK, der 2026 rund 740.000 neue BEV im kommenden Jahr für möglich hält. Vorausgesetzt hat der ZDK die von der Bundesregierung angekündigte Förderung für private E-Autos, eine Bedingung, die auch Grundlage für die Einschätzungen des VDA ist. Die Koalition hatte sich vergangene Woche auf die Wiedereinführung einer Förderung für den privaten Kauf von BEV geeinigt. Es könnte den Plänen zufolge für Haushalte mit einem zu versteuernden Jahreseinkommen von bis zu 80.000 Euro geben, je Kind 5000 Euro mehr. Es solle eine Basisförderung von 3000 Euro festgelegt werden, die für die ersten beiden Kinder um je 500 Euro steige. Der Beginn der Förderung steht aber noch nicht fest.

Für den Gesamtmarkt sieht der VDA kaum Änderungen und rechnet für das kommende Jahr mit insgesamt 2,9 Millionen Pkw-Neuzulassungen aller Antriebsarten, rund zwei Prozent mehr als im laufenden Jahr. Der ZDK sieht im kommenden Jahr einen Anstieg der Pkw-Neuzulassungen um 3,5 bis vier Prozent von rund 2,85 Millionen im Laufenden auf rund 2,95 Millionen im kommenden Jahr voraus. Vom bisherigen Rekordjahr 2019 sind diese Zahlen aber weiterhin deutlich entfernt. Vor der Covid-19-Pandemie wurden fast 20 Prozent mehr Neuwagen zugelassen als die Verbände für 2026 veranschlagen.

ZDK hofft auf „richtige Weichenstellungen“

Als Gründe nennt der ZDK „breitere E-Modellpaletten im Klein- und Kompaktwagensegment, höhere Reichweiten, sinkende Preisunterschiede zwischen Verbrennern und E-Fahrzeugen sowie den fortschreitenden Ausbau der Ladeinfrastruktur“. In der Hoffnung auf eine bereits ab Beginn des Jahres greifende Förderung für Elektroautos nennt er 2026 das „Jahr, in dem die Elektromobilität im Markt wirklich ankommen kann, wenn die Weichen richtig gestellt werden“.

Weiterlesen nach der Anzeige

Laut ZDK drohe ohne diese politischen Entscheidungen in wenigen Jahren ein um 70 bis 80 Cent höherer Kraftstoffpreis, weil ohne substanzielle Steigerung der Elektroautoverkäufe der CO₂-Preis auf bis zu 300 Euro je Tonne steigen könnte. „Mobilität würde zur sozialen Frage, weil Menschen ohne Zugang zu Neuwagen von bezahlbarer Automobilität ausgeschlossen würden“.

Mehr zum Thema E-Mobilität


(fpi)



Source link

Weiterlesen

Beliebt