boost::posix_time::ptime in Millisekunden?
Edzard Egberts
bin ich hier mit Fragen zu den Boost-Bibliotheken richtig? Ich verwende
die gerade massiv, um Programme systemunabhï¿œngig zu machen und da
stellen sich mir doch einige Rï¿œtsel.
Aktuell geht es um boost::interprocess::named_mutex.timed_lock(const
boost::posix_time::ptime& abs_time) - ich finde hier keinen Konstruktor,
mit dem ich diese Funktion aufrufen kann. Zu boost::posix_time::ptime
finde ich nur Konstruktoren fï¿œr einen Zeitpunkt, den Aufruf eines Mutex
versucht man normalerweise aber fï¿œr eine Anzahl Millisekunden und nicht
z.B. bis Heilig Abend 18:00 Uhr.
Was habe ich hier ï¿œbersehen oder nicht verstanden?
Gruￜ,
Ed
Markus Schaaf
> bin ich hier mit Fragen zu den Boost-Bibliotheken richtig?
Ich glaube, das wurde mal so beschlossen. Ansonsten sehe /ich/ das
sowieso eher locker.
> Ich verwende
> die gerade massiv, um Programme systemunabhängig zu machen und da
> stellen sich mir doch einige Rätsel.
>
> Aktuell geht es um boost::interprocess::named_mutex.timed_lock(const
> boost::posix_time::ptime& abs_time) - ich finde hier keinen Konstruktor,
> mit dem ich diese Funktion aufrufen kann. Zu boost::posix_time::ptime
> finde ich nur Konstruktoren für einen Zeitpunkt, den Aufruf eines Mutex
> versucht man normalerweise aber für eine Anzahl Millisekunden und nicht
> z.B. bis Heilig Abend 18:00 Uhr.
Vorneweg: Ich kenne die Sachen nur vom Wegsehen, vermute aber,
Ausgangspunkt war eine spezielle Implementierung um etwas wie `select`
und Pipes oder Sockets herum und das Problem von "spurious wakeups",
verbunden mit dem Problem des (theoretisch) immer ungenauer werdenden
Timeouts bei folgenden Wiederaufrufen. Da bei Boost an solchen Stellen
oft Elfenbeinturm-Design betrieben wird, hat man beschlossen, dass nur
die Angabe eines absoluten Zeitpunkts RICHTIG[tm] ist, weil man den
Timeout ja eh jedesmal neu berechnet. Kann gut sein, dass man dann in
Folge den C'tor mit relativem Timeout weggelassen hat, weil das nur
unnütze User-Convenience ist und höchstens auf exotischen Systemen wie
Microsoft-Windows einen Vorteil böte.
Ich würde mich eher fragen, wenn ich "Programme systemunabhängig ...
machen" wollte, ob ich "named_mutex" für IPC(!) in Applikations-Code
haben wollte, oder doch lieber auf einem viel höheren Niveau abstrahiere
(Message-Queue o.ä.)
Edzard Egberts
>> Boost-Bibliotheken
> Vorneweg: Ich kenne die Sachen nur vom Wegsehen
Ups, wo ist das Problem bei Boost? Ich dachte, dass diese Bibliotheken
in den C++-Standard eingehen, man zur Zeit eigentlich kaum
"zukunftssicherer" programmieren kann und habe aus dieser Gruppe noch
enthusiastische Empfehlungen in Erinnerung (jedenfalls vor ein paar
Jahren, hï¿œtte vielleicht besser 'mal weiter mitgelesen ;o).
Beim Filesystem habe ich zuerst mit POSIX-Funktionen angefangen und bin
dann doch auf Boost umgeschwenkt, weil mir das insgesamt einfacher
erschien und auch einige exotische Sachen anbietet. Womit wï¿œrdest Du
Software machen, die unter Linux und Windows compilieren soll (das ist
hier mit "systemunabhï¿œngig machen" gemeint)?
Ein Boost-Socket, den ich mir zwischendurch gebastelt habe, hat mich
tatsï¿œchlich nicht so ï¿œberzeugt. Wie das funktionieren soll, wï¿œre meine
nï¿œchste Frage gewesen - damit lassen sich scheinbar nur ausgelastete
Verbindungen aufrecht erhalten, so bald der IO_Service.run() verlassen
wurde, scheint mir Schicht zu sein, thread hin und her. Das Beispiel
funktioniert, aber eine Verbindung aufnehmen und einfach nur aufrecht zu
erhalten, klappt gar nicht, dabei wï¿œre dafï¿œr ein IO_Service fast nicht
nï¿œtig...
> Da bei Boost an solchen Stellen
> oft Elfenbeinturm-Design betrieben wird, hat man beschlossen, dass nur
> die Angabe eines absoluten Zeitpunkts RICHTIG[tm] ist, weil man den
> Timeout ja eh jedesmal neu berechnet. Kann gut sein, dass man dann in
> Folge den C'tor mit relativem Timeout weggelassen hat, weil das nur
> unnï¿œtze User-Convenience ist und hï¿œchstens auf exotischen Systemen wie
> Microsoft-Windows einen Vorteil bï¿œte.
Ich bin inzwischen auf die Idee gekommen, dass es wahrscheinlich
irgendwo eine Funktion geben wird, die aus einer relativen Zeitangabe
ein ptime konstruiert. Bin aber noch nicht dazu gekommen, die zu suchen
und die Boost-Dokumentation ist in meinen Augen nicht gerade ein Muster
an ï¿œberschaubarkeit. Man ist da scheinbar auf Geistesblitze angewiesen -
bei meinem Boost-Socket habe ich die Mï¿œglichkeit des Bindens an
Elementfunktionen auch aus der Unmï¿œglichkeit der Instanzenverwaltung
geschlossen, Motto "Das _*MUSS*_ doch irgendwie gehen!".
> Ich wï¿œrde mich eher fragen, wenn ich "Programme systemunabhï¿œngig ...
> machen" wollte, ob ich "named_mutex" fï¿œr IPC(!) in Applikations-Code
> haben wollte, oder doch lieber auf einem viel hï¿œheren Niveau abstrahiere
> (Message-Queue o.ￜ.)
Ich brauche das zum einen, um den Start einer zweiten Instanz zu
verhindern (das geht natï¿œrlich ohne Timeout) und zum anderen, damit ein
Programm, das sich selbst aufruft, auf das Ende der vorhergehenden
Instanz wartet (da wird der Timeout benï¿œtigt). Ist eigentlich genau das,
wofï¿œr ein named mutex auch gedacht ist...
Christian Freund
news:hb21l3$d1q$02$1...@news.t-online.com...
> Ups, wo ist das Problem bei Boost? Ich dachte, dass diese Bibliotheken in
> den C++-Standard eingehen,
Kleine Teile von boost sind in die TR's zum neuen Standard eingegangen und
grￜￜtenteils angenommen worden.
Markus Schaaf
> Am 13.10.2009 14:51, schrieb Markus Schaaf:
>>> Boost-Bibliotheken
>> Vorneweg: Ich kenne die Sachen nur vom Wegsehen
>
> Ups, wo ist das Problem bei Boost?
Vorsicht! Boost ist eine (wie auch immer aufgebaute) Community, die alle
möglichen C++-Bibliotheken entwickelt. Hier ging es aber konkret um
einen bestimmten Ausschnitt.
> Ich dachte, dass diese Bibliotheken
> in den C++-Standard eingehen,
Da gibt es keinen direkten Zusammenhang.
> man zur Zeit eigentlich kaum
> "zukunftssicherer" programmieren kann und habe aus dieser Gruppe noch
> enthusiastische Empfehlungen in Erinnerung (jedenfalls vor ein paar
> Jahren, hätte vielleicht besser 'mal weiter mitgelesen ;o).
Es gibt eine ganze Reihe hochqualitativer Libs in Boost, bei denen man
sich einige Scheiben bezüglich guter Software-Architektur abschneiden
könnte, wenn man wollte. (Genau diese Details werden jedoch meist
ignoriert.)
> erschien und auch einige exotische Sachen anbietet. Womit würdest Du
> Software machen, die unter Linux und Windows compilieren soll (das ist
> hier mit "systemunabhängig machen" gemeint)?
Ich würde damit anfangen, die Schnittstellen zwischen Applikation und
System-Layer nach den Bedürfnissen meiner Applikation zu entwerfen und
erst dann zu schauen, wie ich's implementiere. Toolkits die die
Architektur der Applikation bestimmen, würde ich meiden. Die Idee, dass
irgendwelche Bibliotheken oder Toolkits den Pflegeaufwand einer
Applikation insgesamt verringern, hat sich nicht bestätigt.
> Ich bin inzwischen auf die Idee gekommen, dass es wahrscheinlich
> irgendwo eine Funktion geben wird, die aus einer relativen Zeitangabe
> ein ptime konstruiert.
Sicher: now() + timeout. (Funktionsnamen bei Bedarf anpassen.)
[named mutex]
> Ich brauche das zum einen, um den Start einer zweiten Instanz zu
> verhindern
Zweite Instanz pro /was/? Die Antwort auf diese Frage enthält die Lösung
des Programmierproblems. Meist ist es sowas wie "pro TCP-Port <x>" oder
"pro Config-File". Auf jeden Fall beeinhaltet die Lösung kein Mutex.
> (das geht natürlich ohne Timeout) und zum anderen, damit ein
> Programm, das sich selbst aufruft, auf das Ende der vorhergehenden
> Instanz wartet
Das ist vermutlich ein Designfehler. Wozu brauchst Du das?
Edzard Egberts
> Edzard Egberts schrieb:
> Ich wï¿œrde damit anfangen, die Schnittstellen zwischen Applikation und
> System-Layer nach den Bedï¿œrfnissen meiner Applikation zu entwerfen und
> erst dann zu schauen, wie ich's implementiere.
Das ist mir etwas zu abstrakt - ich habe zwei Bibliotheksdateien, eine
os_fkt.h/.cpp mit Funktionen wie Copy_File(), Move_File(), Mk_Dir(),
etc., eine Fl_Fenster.h/.cpp mit Funkionen wie Fullscreen(),
Top_Window() und dann noch zwei Klassen t_mutex und t_thread. Sockets
und Serielle Schnittstelle laufen schon mit POSIX.
Wenn ich diese Sachen alle mit #ifdef "ï¿œbersetzt" habe (da fehlt nicht
mehr viel, fï¿œr das Fensterzeugs benutze ich direkt die Xlib), kann ich
so etwa 30 Projekte in einem Rutsch unter Linux compilieren. Ich
empfinde dieses Design als hinreichend zufriedenstellend.
Fï¿œr mutex, threads und Filesystem habe ich BOOST vorgesehen, gibt es da
Einwï¿œnde gegen Boost, die fï¿œr eine POSIX-Lï¿œsung sprechen? Wenn das mit
dem mutex ein vermurkster Teil von Boost ist, nehme ich eben POSIX -
dann hast Du mir den Tipp gegeben, bei allem, was bei BOOST
Schwierigkeiten macht, besser die Alternative zu nehmen.
Ich dachte eben nur, dass sich hier jemand damit auskennt.
>> Ich brauche das zum einen, um den Start einer zweiten Instanz zu
>> verhindern
>
> Zweite Instanz pro /was/?
Programminstanz pro PC.
>> (das geht natï¿œrlich ohne Timeout) und zum anderen, damit ein
>> Programm, das sich selbst aufruft, auf das Ende der vorhergehenden
>> Instanz wartet
>
> Das ist vermutlich ein Designfehler. Wozu brauchst Du das?
Nein, das ist Absicht und funktioniert seit Jahren. Ich brauche das,
wenn ich das Programm in einem anderen Kontext neu starten will.