Prozessaufteilung. was wie optimal Nutzen

freaksdd

Kenntnisstand:
Ich studiere Medieninformatik. "gelernt" habe ich die sprachen C,C++,C#,Java,Shell,PHP, ...

also ich weis "bisschen" was über die Sprachen und was es so gibt. doch im studium habe ich auch nicht alle themengebiete von a bis z gelernt. da gehört noch ne ordentliche portion selbststudium dazu was ich gerade betreibe.

das was ich meine mit dem "irgendwie" ist dahin bezogen das es viele wege nach rom gibt. da ich im labor arbeite und verschiedene Sachen teste ... mach ich so oder so eine laufzeitanalyse und so weiter.

mir geht es hier darum verschiedene Möglichkeiten aufgezeigt zu bekommen wie ich "nach Rom komme".

du hast recht das ich den zusammenhang zwar kenne, aber nicht verstehe.
Ich bin noch im Lern-Prozess

freaksdd schrieb:

okay ... ich weis nicht ob ich da falsch erklärt habe bzw sehe ich das mit dem Wlan nicht so tragich, da diese Liste immer länger wird, und kein Speicherzugriffsfehler erscheinen kann. es seid denn der speicher ist voll.

Wenn man unter der Dusche steht und es läuft oben mehr Wasser rein als unten raus, muss man rechtzeitig aufhören. Besser wäre es, wenn das Wasser schneller abläuft.

Die idee mit der Pipe hatte ich auch schon. Ich bekomme von dem Wandler 4 float werte. da muss ich mich noch mal genau nachlesen ob man ein array als pipe nutzen kann.

Nein!

Dein zweiter Vorschlag mit den Threads ist ja im Prinzip das was ich gerne machen würde. jetzt gibt es ja aber verschiedene Varianten und verschiedene Arten von threads. mit pthreads habe ich einen zu hohen CPU-Verlust

Das ist Blödsinn! Wenn du "CPU-Verlust" hast, lässt du den Thread ohne sinnvolle Arbeit rumorgeln. Im Zweifelsfall benötigst du eine Conditionvariable.

Benutze C++11 Threads statt pthreads!

was ich z.B mit openMP nicht habe, da die Prozess-Aufteilung vom Betriebssystem übernommen wird.

Ich kenne OpenMP nicht wirklich, bezweifle aber, das ds für diesen Zweck geeignet ist.

Ich würde gerne die zweite Idee mitnehmen und das aber in openMP lösen. Oder gibt es noch andere gleichwertigere nutzbare Prozessaufteilungen?

das was du sicherlich meinst is so in dieser Art denk ich:

/* beispiel2b.c */
#include <stdio.h>
#include <unistd.h>
#include <pthread.h>

pthread_mutex_t mutex;
char ch;

void *print_stern (void *dummy)
{
  pthread_mutex_lock (&mutex);
  ch = '*';
  sleep (1);
  printf ("%c\n", ch);
  pthread_mutex_unlock (&mutex);
  return NULL;
}

void *print_minus (void *dummy)
{
  pthread_mutex_lock (&mutex);
  ch = '-';
  sleep (1);
  printf ("%c\n", ch);
  pthread_mutex_unlock (&mutex);
  return NULL;
}

int main ()
{
  pthread_t p1, p2;

  pthread_mutex_init (&mutex, NULL);

  pthread_create (&p1, NULL, print_minus, NULL);
  pthread_create (&p2, NULL, print_stern, NULL);

  pthread_join (p1, NULL);
  pthread_join (p2, NULL);

  return 0;
}

Quelle: http://www.ijon.de/comp/tutorials/threads/synchro.html

Das Ist doch nicht mehr als Hello World für Threads.

hustbaer

freaksdd schrieb:

mit pthreads habe ich einen zu hohen CPU-Verlust

Nö, hast du nicht, pthreads vernichtet keine CPUs.
OK, Scherz beiseite, ... hast du trotzdem nicht. Wie kommst du auf die Idee dass PTHREADS so viel Overhead hätte?

Wobei ich eher die Standard C++ Threads empfehlen würde. Weil du dich mit PTHREADS unter Windows z.B. schön brausen gehen kannst. (Ja, ich weiss es gibt auch Implementierungen für Windows, aber die würde ich nicht verwenden wollen.)

freaksdd schrieb:

was ich z.B mit openMP nicht habe, da die Prozess-Aufteilung vom Betriebssystem übernommen wird.

Auch falsch.
OpenMP bringt ne eigene Runtime mit, das OS weiss nix von OpenMP. Ob jetzt PTHREADS Library oder OpenMP Runtime - wo soll der Unterschied sein?

SeppJ

Noch genauer: Alles was in POSIX irgendwie mehrere Threads benutzt, benutzt unter der Haube letztlich pthreads. OpenMP, C++11, egal wer. Denn das sind die Threads, die das OS bereit stellt, es gibt keine anderen. Das gilt gleichermaßen für alle anderen Systeme. Niemand (auch OpenMP) implementiert seine eigenen Threads. Wie sollte das auch gehen? Interprozesskommunikation? Das ist doch wahnsinnig umständlich verglichen mit den Threadmechanismen, die das OS direkt bereit stellt und ist selber auch nur ein weiterer OS-Mechanismus (eben eine Ebene höher).

freaksdd

okay ... ich habe soweit erstmal verstanden.
das mit den cpu-Verlust hab ich nur gelesen und wird nicht empfohlen da egal welcher thread es immer zu mehr cpu-last kommt als wenn man keine hat. da stand was von 2-15 % mehr last.

mit dem Thema Threads habe ich mich hier wahrscheinlich biss lächerlich gemacht weil ich das nicht wirklich kenne und nur nachgelesen habe.
Es ist aber schön zu wissen das es euch gibt die mehr ahnung davon haben und dafür bedanke ich mich sehr.

Ich werde es jetzt so machen:
Ich probiere es ohne threads + mit threads(verschiedene arten)

da ich bei den threads nun wirklich keine ahnung habe würde ich gerne wissen welche arten ich in c++ probieren kann?
Ich werde alle testen und die laufzeit messen. Und das Programm was am schnellsten und zuverlässigsten läuft werde ich dann wahrscheinlich auch verwenden.

SeppJ

freaksdd schrieb:

da ich bei den threads nun wirklich keine ahnung habe würde ich gerne wissen welche arten ich in c++ probieren kann?

Willst du wirklich eine komplette Liste? Die ist entweder sehr kurz (reines Standard-C++ kennt nur seine eigenen Threads) oder sehr lang (es gibt unzählige Threadingbibliotheken). Letzteres ist auch irgendwie sinnlos. Eine abstrakte Schnittstelle wie OpenMP ist für ganz andere Szenarien optimiert als eine low-level Schnittstelle wie die rohen pthreads. Die Wahl sollte daher nicht erfolgen, indem du verschiedene, von dir geschriebene Programme vergleichst, sondern indem du dir vorher überlegst, was für deinen Anwendungsfall die optimale Wahl wäre. Brauchst du Feinkontrolle? Dann ist eher eine low-level Schnittstelle gefragt. Zählt eher einfaches Entwickeln? Dann ist eine höhere Abstraktionsstufe besser.

Ich werde alle testen und die laufzeit messen.

Wenn du es wirklich bis zum Gipfel treibst, dann wird immer die low-leveligste Schnittstelle gewinnen, weil du mit der Sachen machen kannst, die mit höherstufigen Schnittstellen nicht gehen. Aber dafür entwickelst du halt 2 Tage statt 2 Stunden am gleichen Programm. Wie willst du das vernünftig vergleichen?

Und das Programm was am [...] zuverlässigsten läuft [...]

Am zuverlässigsten? Ein Programm ist entweder richtig oder eben nicht. Da gibt es keine Abstufungen. Wenn es einen einzigen Fall gibt, wo es nicht richtig läuft, dann ist das Programm falsch. Ich hoffe, du benutzt nur richtige Programme und du programmierst so, dass deine Programme möglichst auf Anhieb richtig sind.
Das gilt ganz besonders bei parallelen Programmen, bei dem gewisse Fehler nichtdeterministisch auftreten können. Wenn dein Programm abundzu einen Deadlock hat und abundzu nicht, dann ist es falsch, selbst wenn es in 90% der Fälle keinen Deadlock hat. Basta!

freaksdd

hi,
mir würde ni kleine übersicht der c-Bibliotheken reichen. möglichst nicht viel andere Bibliotheken.
Ich würde schon gerne die standarts nutzen wollen von threads mit denen man halt gute erfahrungen gemacht hat bzw man sich sicher ist das die zuverlässig ihre funktion erfüllen ohne großes hin und her.

wichtig dabei ist das die beiden threads auf den selben speicher zugreifen und es da eine einfach funktion gibt um konflikte zu vermeiden zb "lock" oder sowas.
nun habe ich schon mal mit lock gearbeitet oder ähnlichem. wie ist das bei einer vereinfachten kette. das müsste ja genau so funktionieren wenn man dien speicherbereich sperrt. das lesen aus der liste kann verzögert sein falls das schneller als das reinschreiben in die liste sein sollte. nur das schreiben sollte möglichst schnell und sicher erfolgen.
PS: es gab nun andere kriterien vom Prof wo nur das schreiben in die Liste am schnellsten und zuverlässigsten sein muss. das lesen aus der kette kann verzögert sein.

was könnt ihr mir dementsprechend anbieten? ich würde das jetzt erstmal klassisch über pthread machen.

kann man statt 2 threads auch den hauptprozess und einen thread nehmen? bei pthread denk ich ist das so das beide threads beendet werden müssen bevor der "master-prozess" weiter macht. lieg ich da richtig oder falsch? bitte korrigiert mich.

und immer wieder besten dank für eure tips und mühe

SeppJ

freaksdd schrieb:

hi,
mir würde ni kleine übersicht der c-Bibliotheken reichen.

Wieso denn jetzt auf einmal C, wenn du doch C++ machst?

wichtig dabei ist das die beiden threads auf den selben speicher zugreifen und es da eine einfach funktion gibt um konflikte zu vermeiden zb "lock" oder sowas.

Das ist Grundfunktion, ohne die man Threads gar nicht nutzen könnte. Eine Threadbibliothek, die das nicht bietet, gibt es nicht auf der Welt.

kann man statt 2 threads auch den hauptprozess und einen thread nehmen?

Ja, selbstverständlich.

freaksdd

ich mein natürlich c++, sorry.

ich bin gerade dabei mir die bibliothek von "boost" zu installieren. also boost::thread. is die zb empfehlenswert?

Moment: Willst Du oder musst Du eigentlich Threads verwenden?

Mir kommt es etwas spanisch vor, dass Du mittlerweile boost installierst, aber von std::queue noch nix gehoert hast.

Und dann (sorry, wenn das schon beantwortet wurde): Benutzt Du C++11?

freaksdd

das mit dem "muss" oder "kann" -verwenden is so ne sache. je nachdem was besser ist von der leistung her. ich muss es probieren was schneller und sicher ist.

ich bin gerade mächtig bei google unterwegs um herauszufinden was es alles an thread bibliotheken gibt und probier die halt alle mal aus. momentan bin ich bei boost ... aber da habe ich noch probleme beim kompilieren.

ich arbeite mit dem raspberry pi und debian.
bei der versionsabfrage von g++ kommt bei mir "(debian 4.5.3- 14+rpil) 4.6.3
ich schau gerade ob das die aktuellste ist die man auf debian nutzen kann.

freaksdd schrieb:

das mit dem "muss" oder "kann" -verwenden is so ne sache. je nachdem was besser ist von der leistung her. ich muss es probieren was schneller und sicher ist.

Gerald M. Weinberg schrieb:

If it doesn't have to produce correct results,
I can make it arbitrarily fast.

freaksdd schrieb:

ich bin gerade mächtig bei google unterwegs um herauszufinden was es alles an thread bibliotheken gibt und probier die halt alle mal aus. momentan bin ich bei boost ... aber da habe ich noch probleme beim kompilieren.

Du verschwendest Zeit.
Mit dem 4.6.3 und im Jahre des Herrn 2014 wirst Du C++11 benutzen.
Nimm dann auch die Threads aus der Standardbibliothek.
Wenn überhaupt.
Das ist jedenfalls meine bescheidene Meinung.

Ist denn Dein Programm "Single Threaded" schon fertig und zu langsam?

freaksdd

ich hab schon mal geschaut wie man das mit dem c++11 übersetzt. würde theoretisch funktionieren.
was kann ich mir unter der aktuellen version von c++ vorstellen? wird das schneller übersetzt oder gibt es nur zusätzliche Funktionen?

jein ... das Programm ist noch in einzel stücke und muss noch zusammen gesetzt werden. im groben und ganzen ist es aber faaaast fertig

SeppJ

freaksdd schrieb:

was kann ich mir unter der aktuellen version von c++ vorstellen?

http://en.wikipedia.org/wiki/C%2B%2B#Standardization

wird das schneller übersetzt

Nein, eher langsamer. Aber ich glaube, du hast eine völlig falsche Vorstellung, was du da gerade gefragt hast. Begriffe, die du momentan vermutlich nicht richtig einordnest:
-Programmiersprache
-Programm
-Compiler
-C++
Mach dich mal schlau.

Wenn du solche Wissenslücken hast, dann sind Threads noch ferne Zukunftsmusik für dich.

oder gibt es nur zusätzliche Funktionen?

Dies.

freaksdd

aaaaaaaalso ... ich hab mein programm erstmal so geschrieben das es ohne threads sequenziell nacheinander alles abarbeitet.
Jetzt habe ich noch mal mit dem Support des AD-wandlers geschrieben und er meinte:
[][][]
In C++ empfehle ich Ihnen die Verwendung von std::thread (http://en.cppreference.com/w/cpp/thread/thread/thread) und std::async (http://en.cppreference.com/w/cpp/thread/async), dafür wird das PThread im Linux aber auch benötigt. Beide Sachen funktionieren aber nur, wenn Sie C++11 aktivieren (in CMAKE mit -> add_definitions("-std=c++11")).
[][][]

... da gelange ich auf das nächste Problem. wo trage ich das -std=c++11 ein?
hier mal das Makefile was mir vom AD-Wandler zur Verfügung gestellt wurde:

project(msrexamples)
cmake_minimum_required(VERSION 2.8)
cmake_policy(SET CMP0015 NEW)

set(VERSION 1.4)

# Short path to project.
set(ROOT ${CMAKE_HOME_DIRECTORY})

# Check for 32 or 64 bit.
if(CMAKE_SIZEOF_VOID_P EQUAL 4)
	set(HAVE_64_BIT 0)
else()
	set(HAVE_64_BIT 1)
endif()

# Set target specific output path.
set(EXECUTABLE_OUTPUT_PATH ${ROOT}/bin)
set(LIBRARY_OUTPUT_PATH ${ROOT}/lib)
link_directories(${ROOT}/lib)

# Depending on tool-chain, define library path ...
# Visual Studio requires libs, either 32 or 64 bit.
if(MSVC)
	if(HAVE_64_BIT)
		set(LIB_NAME cebomsr-${VERSION}-x86_64)
	else()
		set(LIB_NAME cebomsr-${VERSION}-x86)
	endif()
	link_directories(${ROOT}/lib)
endif()

# MinGW directly links against the .DLL's, either 32 or 64 bit.
if(MINGW)
	if(HAVE_64_BIT)
		set(LIB_NAME cebomsr-${VERSION}-x86_64)
	else()
		set(LIB_NAME cebomsr-${VERSION}-x86)
	endif()
	link_directories(../runtime)
endif()

# POSIX links against .so .
if(UNIX)
	link_directories(../runtime)
	set(LIB_NAME cebomsr-${VERSION})
endif()

# Include path is always constant.
include_directories(${ROOT}/api/)

# API is constant for all examples.
set(API_FILES ${ROOT}/api/cebomsrpp.cpp ${ROOT}/api/cebomsrpp.h ${ROOT}/api/cebomsr.h)
source_group(Api FILES ${API_FILES})	

# The examples.
foreach(EX counter frameio info singleio streamingi trigger zz)
	add_executable(${EX} ${ROOT}/examples/${EX}.cpp ${API_FILES})
	target_link_libraries(${EX} ${LIB_NAME})
endforeach()

freaksdd schrieb:

aaaaaaaalso ... ich hab mein programm erstmal so geschrieben das es ohne threads sequenziell nacheinander alles abarbeitet.

Gut. Und es ist zu langsam?

freaksdd schrieb:

Jetzt habe ich noch mal mit dem Support des AD-wandlers geschrieben und er meinte:
[][][]
In C++ empfehle ich Ihnen die Verwendung von std::thread (http://en.cppreference.com/w/cpp/thread/thread/thread) und std::async (http://en.cppreference.com/w/cpp/thread/async), dafür wird das PThread im Linux aber auch benötigt. Beide Sachen funktionieren aber nur, wenn Sie C++11 aktivieren (in CMAKE mit -> add_definitions("-std=c++11")).
[][][]

... da gelange ich auf das nächste Problem. wo trage ich das -std=c++11 ein?

Du hast also ein Problem mit der Konfiguration von CMake, nicht mit C++.

Vielleicht beschreibst Du Dein Problem im Compiler/IDE Forum, oder in Rund um die Programmierung.
Schreib aber auch gleich noch für welche(n) Compiler Du C++11 Support aktivieren möchtest.

freaksdd

also zu langsam kann ich nicht wirklich äußern da ich noch kein vergleich mit threads machen konnte.
ich lese mit dem raspberry pi problemlos mit 1000Hz 4x25 (25 = Puffergröße) Messwerte aus(AD-Wandler besitzt einen internen Puffer). Das senden der Daten erfolg nach beenden der Messung. Dadurch klappt alles reibungslos doch es verlängert halt die ganze komplette sache.
mit threads wollt ich den ganzen vorgang etwas verkürzen. ich werd mal sehen was sich da machen lässt.
danke für den tipp ... da werd ich mal mit dem Compiler/IDE Forum auseinandersetzen und schauen was ich erreichen kann.

weiß jemand wo ich eine genaue beschreibung mit beispielen(nicht unbedingt) zu den std::thread finden kann? also ich suche genau beschreibungen der funktionen, flags, ...

Danke an alle Antworten. Ihr habt mir schon etwas "beibringen" können. im studium bekommt man halt leider auch nicht alles gelernt.

Caligulaminus

freaksdd schrieb:

mit threads wollt ich den ganzen vorgang etwas verkürzen.

Wenns dir um die Geschwindigkeit geht: Hat dein Raspberry überhaupt mehr als einen Kern?

freaksdd

der raspberry hat nur 1 kern mit satten 700 Mhz .
den AD-Wandler lese ich momentan mit 1Mhz aus was recht schnell und zuverlässig läuft. da aber mehr Herz am Raspberry zur Verfügung stehen könnte man nebenbei einen weiteren Prozess laufen lassen ... das war zumindest mein Gedanke. Ich wollte es testen und schauen ob das überhaupt möglich ist mit 1Mhz Daten lesen und nebenbei einen weiteren Prozess laufen zu lassen.

hustbaer

Wenn du den Wandler mit 1 MHz auslesen willst, dann musst du dafür sowieso schon alle Interrupts sperren.
Sonst macht dein Thread einfach mal so pause - und das deutlich länger als die 700 Zyklen die du theoretisch zwischen 2x Lesen des Wandlers "zeit hast".