Shared Memory
-
Ja genau.
Die Idee von dir hätte ich jetzt auch so gemacht, aber wie du auch schon sagst, das ist nicht gerade das gelbe vom Ei...
-
@krümel...
Darum geht es nicht.....
Nochmal frage lesen oder mutex verstehen =).
-
Wie wärs dann mit Pipes? In manchen C Bibliotheken gibts die Funktion popen, oder alternativ die Windows Funktion CreatePipe. Oder du benutzt Sockets dafür.
-
Also soweit ich weiß sind sockets etwas langsamer, dafür kann man da aber auch über internet kommunizieren.
Hab mich schon für shared mem (boost.Interprocess) entschieden.
Erzwingt boost.Interprocess message queue bei einem Send einen Prozesswechsel ??
-
Offenkundig brauchst du sowas wie einen Signalisierungsmechanismus. Evtl. gibt es dafür bereits bei Boost.Interprocess was. Falls nicht, kannst du einen Mutex verwenden (oder einen passenderen Lock), der den zu signalisierenden Prozess immer dann passieren lässt, wenn es was neues gibt (also P1 hält den Lock, P2 versucht acquire, P1 gibt frei, sobald es was zum lesen gibt; ist halt sehr low-level).
Alternativ kannst du Messages, zum Beispiel Boost.MPI verwenden. Ohne Kontext ist es schwer, zu entscheiden, was hier richtig ist.
-
Sag ich doch ein Mutex...
-
Also ich hab mir die Fragestellung nochmal durchgelesen.
Die ist doch etwas unverständlich =).Das ich mit Mutex blockieren kann weiß ich und wußt ich auch schon als ich die Frage gestellt hab.
Ich möchte explizit sagen wenn p1 mit schreiben fertig ist, soll p2 direkt lesen.
Ich möchte vermeiden, dass die Prozesswarteschlange zum Beispiel
p1 p34 p234 p2345 p98 ...... p2
bearbeitet.Mutex verwende ich so oder so, ist aber ne andere Baustelle.
Mutex -> p1 überschreibt keinen Speicher bevor er gelesen wurde.Also Mutex beantwortet die Frage:
Wie kann ich Prozess p1 klar machen, dass er nicht mehr in den Speicher schreiben soll, wenn er noch nicht gelesen worden ist. (Zumindest so wie ich die Mutex verwende. )Wobei ich nicht weiß ob immer gleich p2 nach p1 überhaupt gut ist. =).....
Aber das ist auch ne andere frage
-
AlexanderKiebler schrieb:
Das ich mit Mutex blockieren kann weiß ich und wußt ich auch schon als ich die Frage gestellt hab.
Ich möchte explizit sagen wenn p1 mit schreiben fertig ist, soll p2 direkt lesen.
Ich möchte vermeiden, dass die Prozesswarteschlange zum Beispiel
p1 p34 p234 p2345 p98 ...... p2
bearbeitet.Welcher Prozess wann dran ist bestimmt das Betriebssystem. Da du vermutlich Linux oder Windows benutzt, kannst du darauf so gut wie keinen Einfluss nehmen. Wenn du dem Prozess eine hohe Priorität gegenüber den anderen gibst, wird er vom Betriebssystem bevorzugt ausgewählt. Du müsstest ihn dann trotzdem per Mutex o.ä. blockieren, bis er dran ist.
Frage: worin liegt denn der Sinn deiner Bemühungen? Warum soll das Betriebssystem nicht einfach seine Arbeit machen?
Lars
-
Hi Lars,
Wie bereits gesagt ist das eine andere Frage. --> Strategische Frage
Hatte gehofft boost würde ne Möglichkeit bieten explizit von einem auf einen anderen Prozess zu wechseln.
Wenn ich mit Mutex arbeite ist das ja so ähnlich wie pollen,
Wenn ich direkt wechseln könnte, wäre das eben wie interrupt gesteuert.
(Das war meine Motivation mal nach zu fragen)Wobei ich dir Recht geben muß, all zu sinnvoll ist das nicht.
Trotzdem hat mich das interessiert. Ich dachte wenn mal eine Kommunikation zwischen zwei prozessen sehr sehr zeitkritisch ist wäre das sehr sinnvoll.
Wobei wenn das jeder Programmierer machen würde, würden Prozessketten entstehen, welche dem benutzer das gefühl geben würden, der PC ist eingefroren....Aber danke für Antwort.
-
Ich frage mich ob es guter Stil wäre, eine Endlosschleife in einen Thread zu packen und per Callback jedesmal die Funktion aufzurufen. Oder sogar einen fnc-ptr-pool anzulegen, der dann jeweils die Funktionen aufruft.
Hm...
-
Für zeitkritische Sachen brauchst du ein Echtzeitsystem, da kommst du nicht drum herum. Das eheste, wie du noch Einfluss nehmen kannst, ist die Threads deines Prozesses zu yielden, und über die Prioritäten.
Aber selbst wenn du damit das gewünschte Verhalten hinkriegst, kann es sich wieder unterscheiden, wenn jemand nen Quadcore statt nen Dualcore hat, oder wenn er nebenbei was rechenintensives am Laufen hat.