Zitat von
hurzli:
Ich hatte garnicht erwartet, dass sich nochmal jemand rührt !
Ich gehe unregelmäßig alle Postings durch und schaue in die die mich interessieren und unbeantwortet sind oder wenige (0-2) Antworten haben.
Zitat von
hurzli:
Die anzusteuernden "Geräte" sind keine normale Computerperipherie sondern komplette automatische Lagersysteme, Paternosterlager, Rotomaten etc. Diese Geräte werden mit Aufträgen versorgt und melden ihre Aktionen zurück (So im Groben). Jeder Lagertyp auf seine eigene Art. Die dabei anfallenden Daten und die benötigte Rechenleistung um diese Daten zu verarbeiten sind eher gering.
Okay. Theoretisch geht ein Gerätetreiber auch für einen Toaster (das
DDK kommt mit einem solchen Bsp) aber vielleicht wäre das mit der Einarbeitungszeit tatsächlich Overkill.
Zitat von
hurzli:
In der Threadtechnologie bin ich ein gebranntes Kind, denn die verschiedenen Threads kommen manchmal auf Ideen bzw. in Zustände, auf die ich im Traum nie gekommen wäre. Alles in Allem strotzen die meisten Multithreadanwendungen die ich so gesehen habe von CriticalSections. Alle Threads warten meistens darauf, dass einer mit irgendwas fertig wird. Eigenlich hätte man's dann auch gleich sequentiell lösen können.
Dann hast du nur die schlechten Bsp. für Synchronisation erlebt. Schau dir den Apache-Server an, der ist ein gutes Beispiel
Jeder Thread kann ja einen eigenen Puffer haben, der erst dann geschrieben wird "wenn was frei ist". Es geht also auch ohne daß die sich gegenseitig blocken. Allerdings muß man sich gut überlegen was in einen Thread soll. Außerdem ist die Delphi-TThread-Klasse auch nicht dazu angetan solche Dinge zu machen. Entweder was eigenes schreiben oder direkt mit Threads und deren APIs arbeiten.
Zitat von
hurzli:
Weil hinter so einem wie auch immer gelösten Programmteil eine reelle Fertigung steht und es bei
deren Ausfall gleich so richtig ums Geld geht, geht mir die Sicherheit der laufenden Programmteile vor. Ressourchen und Eleganz sind in diesem Fall nur "Grauwerte".
Was war jetzt eigentlich das Problem. Vielleicht habe ich es ja komplett falsch verstanden. Also ich hatte es so aufgefaßt, daß du pro Gerät dynamisch einen neuen Dienst erzeugst und dies Namenskonflikte bringt. Wenn dem nicht so ist, verstehe ich wohl das Problem noch nicht ganz.
Alternativ zu Threads kannst du unter NT (und 2000, XP ...) auch Fiber verwenden. Grob gesagt sind dies Usermode-Threads und du kannst sie selbst schedulen. Im Falle von Threads macht dies der Scheduler im KM für dich.
Zitat von
hurzli:
Eigentlich ist das Problem bereits gelöst.
Gut
Zitat von
hurzli:
Versucht hatte ich die TService-Komponente von Delphi 5.
Die hat meiner subjektiven Meinung nach einen Fehler. Als Dienstname wird der TService.Componentname in die Registry eingetragen und der ist nicht der Name, den ich dem Dienst über mein Konfigurationsprogramm eingetragen hatte. DESHALB lief der Dienst einfach nicht los. Falscher Name, das ist alles.
Ist das in D5 Pro bereits drin? Dann würde ich es mal bei uns im PC-Pool testen. Privat hab ich nur D4 Pro.
Zitat von
hurzli:
Die Lösung : ein in Delphi 3 geschriebenen Dienst, der sich noch so richtig zu Fuß um alle Einträge/Aktionen selbst kümmert, auf meine Anforderungen angepasst, bringt's. Also eine Delphi 3 Dienst-Hülle mit meiner Funktionalität, wenn man das ganze so nennen will.
Und die Hülle startet "Prozesse" oder "Dienste" (ich weiß, daß Dienste auch Prozesse sind!)?
Gruß,