| |
|
|
| freenet.thorsten_friedrichs meint:
ich habe mich ein bissl im Forum umgeschaut und auch von RGH was gefunden, | |
aber sagt mal, ist Profan denn nun Multithreadfähig oder nicht? | |
|
|
|
| |
|
|
|
| |
|
| |
|
|
|
| |
|
| |
|
|
|
| RGH meint:
Thorsten Friedrichs schrieb: | |
> ich habe mich ein bissl im Forum umgeschaut und auch von RGH was gefunden, | |
> aber sagt mal, ist Profan denn nun Multithreadfähig oder nicht? | |
JA und NEIN! | |
JA: Da XProfan aPI-fähig ist und die ganze Windows-API nutzen kann, kann | |
man darüber natürlich auch sehr gut Multithreadingfähige Programme | |
erntwickeln. Dazu muß man sich aber in die Windows-API einarbeiten oder | |
fertige Routinen benutzen. Meines Wissens gibt es auch www.xprofan.com | |
von David Strutz, geannt iF) eine passende XProfan-Unit. | |
NEIN: XProfan hat ohne API-Verwendung keine speziellen | |
Befehle/Funktionen für Multithreading. | |
|
|
|
| |
|
|
|
| freenet.thorsten_friedrichs meint:
Also Multithreads an sich zu nutzen in Profan (über API oder meine DLL) ist | |
an sich nicht das Problem, | |
nur muß man dazu die Procedureadresse haben. | |
Wenn ich also eine Profanprocedure aufrufe muß ich diese Adresse kennen um | |
Multithreads sind Grundlegend ja nicht anderes als selbständige Proceduren. | |
Ähnlich Callbacks, wenn nicht sogar das selbe !? | |
Nur wie könnte das gehen? | |
Ich habe mal mit deinem Beispiel aus dem Forum wo es um einen Aufruf einer | |
PRofanprozedure mit der API Settimer probiert. | |
Dies umgebaut, mit mehren Thread zum test aufgerufen, aber es klappt nicht | |
Es konnte nach meinen Test immer nur eine Procedure aufgerufen werden. Mit | |
procaddr ermittelte ich die Adresse, | |
rief ich aber 2 gleichzeitig auf, so klappt das nicht, zwar schienen beide | |
aufgerufen zu werden, aber entweder kam intern in Profan was durcheinander, | |
denn die als zweite aufgerufene übernahm die Datenausgabe bzw. es kam malzu | |
einem nicht nachvollziehbaren Fehler oder der die erste Procedure / erste | |
Thread wurd durch Profan angehalten. | |
Ähnlich wie bei deinem Settimerbeispiel was sehr schön ist, aber ich nur | |
durch einen Tastendruck die Datums und Zeitausgabe auslösen konnte, wenn | |
die durch settimer ausgelöste Procedure beendet war. | |
Mein Problem also ist, das ich es nicht geschafft habe 2 Proceduren korrekt | |
Geht es denn mit Profan überhaupt 2 Proceduren (adresse durch procaddr) | |
gleichzeitig aufzurufen und laufen zu lassen? | |
Da der Profancode / Compilat ja interpretiert wird rufe vermutlich eine | |
deiner Delphiproceduren auf, die dann den Code interpretiert. Es kommt jetzt | |
soweit ich das bisher verstanden habe also darauf an, wie DEIN code arbeitet | |
und ob er zuläßt zweimal aufgerufen zu werden. | |
Wenn die Routine (/ Profan ) die man über procaddr aufruft so ausgelegt ist, | |
das sie vielleicht nur globale Variablen verwendet dann wird es wohl nicht | |
Im Speicher steht irgend ein Code, ich denke mal ne Delphiprocedure und die | |
Was also passiert wenn diese gleichzeitig aufgerufen wird? | |
Soweit ich verstanden habe (was natürlich noch teilweise falsch sein kann) | |
wir für jeden Aufruf ein einger Stack genutz (hoffentlich richtig | |
ausgedrückt), Variablen aus den unterschiedlichen Procedureaufrufen | |
beeinflussen sich also nicht, es sei denn es werden dort irgendwo globale | |
Delphivariablen oder -funktionen genutzt. | |
In Profan als Wäre das so, als wenn 2 Thread gleichzeitig ne DBasedatenbank | |
nutzen, wären der eine Minuten land einen Datensatzt beschreibt und ändert | |
(den selben) ändert der zweite mit dbgo den Datensatz, was natürlich den | |
ersten auch beeinflußt und Fehler auslöst. | |
In PB geschieht das z.B. mit LinkedLists und sogar Strings. | |
Also es ist für mich persönlich nicht besonders wichtig, da ich ja eh ne DLL | |
erstelle und das da mache(n kann). | |
Aber es wäre schön zu wissen ob und wie es geht, erstens weil ich dann die | |
Aufrufe so erstellen kann, das die dies berücksichtigen (wenn auch noch | |
nicht in der ersten Version) und zweitens kann man dann entweder über die | |
Api (wie mit Settimer) oder aus der DLl diesen Thread aufrufen. | |
Und da ich gerne immer mal teste und fummele habe ich da gestern halt im | |
Forum gesucht und dann hier getest, aber diese komische Verhalten bei den | |
Profanproceduren per Callback/procaddr erlebt. | |
Also wie gesagt, für mich persönlich nicht wichtig ob es geht oder nicht, | |
aber wenn ich schon mal dabei bin... | |
Ich brauche manchmal Ablenkung von meinem eigenen Programmcode der einen | |
irgendwie immer mal wieder ankot.. | |
> -----Ursprüngliche Nachricht----- | |
> Von: Roland Hülsmann [mailto:rgh-soft@t-online.de] | |
> Gesendet: Mittwoch, 22. Februar 2006 13:04 | |
> Betreff: Re: Multithread | |
> Thorsten Friedrichs schrieb: | |
> > ich habe mich ein bissl im Forum umgeschaut und auch von RGH | |
> > aber sagt mal, ist Profan denn nun Multithreadfähig oder nicht? | |
> JA und NEIN! | |
> JA: Da XProfan aPI-fähig ist und die ganze Windows-API nutzen kann, kann | |
> man darüber natürlich auch sehr gut Multithreadingfähige Programme | |
> erntwickeln. Dazu muß man sich aber in die Windows-API einarbeiten oder | |
> fertige Routinen benutzen. Meines Wissens gibt es auch www.xprofan.com | |
> von David Strutz, geannt iF) eine passende XProfan-Unit. | |
> NEIN: XProfan hat ohne API-Verwendung keine speziellen | |
> Befehle/Funktionen für Multithreading. | |
> WICHTIGER HINWEIS FÜR PROFAN-SUPPORT: | |
> Offizielle Homepage: [...] | |
> Technische Anfragen (Programmierung, Bugs, etc.) bitte NUR über folgende | |
> a) PROFAN-Mailingliste: [...] | |
> b) PROFAN-SUPPORT-Foren: [...] | |
> Der neue PROFAN-FAN-SHOP: [...] | |
> Das kostenlose Kartenspiel: [...] | |
> Um sich von dieser Gruppe abzumelden, klicken Sie bitte hier: | |
https://www.domeus.de/public/unsubscribe.jsp?gid=240771&uid=264849&mid=312950 | |
Die Nutzung von domeus unterliegt den AGB der eCircle AG: | |
https://www.domeus.de/info/terms.jsp , | |
die Sie durch weiteren Erhalt von eMails durch domeus akzeptieren. | |
|
|
|
| |
|
|
|
Michael Wodrich | Auszug aus der Hilfedatei: (ab XProfan) @ProcAddr(Name einer Prozedur, Anzahl der übergebenen Parameter) Ergebnis : Adresse Diese Funktion wird z.B. für CallBack-Funktionen benötigt. Sie weist einer Prozedur des XProfan-Programmes eine Speicheradresse zu, über die andere Programme diese Prozedur aufrufen können.
s.a.: 28.12 - CallBack-Funktionen
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 22.02.2006 ▲ |
|
|
|
|
| t-online.drcrr meint:
Thorsten Friedrichs schrieb: | |
ich lese hier jetzt schon eine ganze Zeit mit, da ich auch mit Datenbanken (allerdings dBase) arbeite und das Zeit-Problem bei indizierten Datenbankendort eigentlich nicht kenne, da z.B. in meiner Anwendung bei 140.000 Datensätzen eines Kunden, die Fundstelle zeitgleich erfolgt, habe das allerdings nicht in millisek. gemessen. | |
Das größte Hindernis war bisher die fehlende Multitasking-Fähigkeit von dBase, zumindest die in Profan. Aufforderungen, da etwas zu entwickeln, sind ja leider nie umgesetzt worden. | |
Da gibt es aber eine Lösung, die auf einer dBase Open-Source-Entwicklung beruht. Die Entwickler haben alle Codes ins Internet gestellt, Adresse kannich im Moment nicht finden aber wieder besorgen, da ich die fertige DLL benutze, die im Zusammenhang mit einem anderen kommerziellen Multimedia-Autoren-System von dessen Entwickler als plugin (dll) kostenlos zur Verfügung gestellt wird. Meine damit erstellten Programme sind alle seit 2 Jahren kommerziell im Einsatz und Mehrplatzfähig. Nur pack() verlangt den exklusiven Zugriff. | |
Der Feldumfang ist gegenüber dBaseIII wesentlich erweitert und umfaßt z.B. auch Währungen, largeIntegers und Bilder(!) in Feldern. Befehle fürTabellen und Reportings liefern professionelles Design inkl. Steuerbuttons. Die Ergebnisse sind sprachunabhängig, wenn auch vom Programmierumfeld alles in Englisch ist. | |
Der Befehlsumfang dieser DLL (432 kB) ist enorm - lege die Überschriften mal bei - und die Schnelligkeit der Index-Suche mit/ohne Query-Befehl auch für kommerzielle Anwendungen optimal. Aber vielleicht trifft das ja auch nicht Deine Zielsetzung und Deinen Ehrgeiz, etwas Neues zu entwickeln ... | |
Also vielleicht ist dieser OpenSourceCode von Interesse (die DLL ist für Profan nicht zu gebrauchen!) Wenn gewünscht, besorge ich die Adresse aus USA ... | |
____________________________________________________ | |
This section contains descriptions of each of the Action commands | |
dbfSetImportExportOptions | |
dbfClearHeadersAndFooters | |
|
|
|
| |
|
|
|
| freenet.thorsten_friedrichs meint:
Ich werde mir die commands aus interesse gleich mal an, Aber es geht mir ja | |
NICHT eine Dateidatenbank. | |
Na noch nicht, das kommt erst später, da werde ich aber wohls eigenes | |
Indizierte Datenbanken sind natürlich schneller, aber erstens muß dieser | |
Index erstellt und gepflegt werden, zweitens muß aber auch gesucht werden. | |
Wie machst du das? Nutzt du einfach als aufruf ne Nummer für den Datensatz, | |
das wäre dann ja recht einfach und schnell zu handhaben wenn die eine | |
eindeutige auf einanderfolgende Zahl/Zahlenkette ist. | |
Aber wenn man die Datenbank nach einem Namen durchsucht, Artikel oder | |
Kundennummer muß man immer irgendwie suchen. | |
Und das dauert dann auch. | |
Ob man nun von der Festplatte lies oder RAMspeicher durchsucht macht zwar | |
schon einen geschwindigkeitsunterschied, aber nicht so extrem. Denn entweder | |
wird der Index (oder die Datei) direkt auf der Festplatte durchsucht oder | |
der Index in den RAM reladen. Bei z.B. 140 000 Datensätzen könnte eine | |
Indexdatei bei sagen wir mal 10 Bytes (Kundennummer) pro Indexeintrag 1,4 MB | |
Groß sein. Bei 30-40 MB Lesegeschwindigkeit der Festplatte dauert das laden | |
von der Platte also auch nicht so lange (wenn im Block gelesen wird) aber | |
die Vergleiche oder überprüfungen (bei Multiuser) dauert natürlich auch. | |
Mich würde zwar schon interessieren, wie lange die Suche dauert nach dem | |
letzten Datensatz der Datei (dem letzten im Index), aber das läst sich ja | |
Der Zufriff auf DBASE mit Profan ist ja zum glück einfach und auch von der | |
Geschwindigkeit her vermutlich so wie bei allen anderne Programmen, denn den | |
Zugriff übernimmt ja Profan und man muß keinen eigenen QUellcode erstellen | |
(nur die paar Zugriffsfunkionen). | |
ich erstelle gerade eine Datenbank mit 140 000 Datensätzen und einen Index, | |
aber das dauert leider eweig. Dauert schon minuten, liegt natürlich an dem | |
Index, das dauert manchmal sehr lange. | |
Mal sehn ob das heue noch was wird. | |
Warum ist den die DLL für Profan nicht zu gebrauchen? | |
> -----Ursprüngliche Nachricht----- | |
> Von: Christian Roosen-Runge [mailto:drcrr@t-online.de] | |
> Gesendet: Mittwoch, 22. Februar 2006 15:47 | |
> Betreff: Re: AW: Multithread | |
> Thorsten Friedrichs schrieb: | |
> ich lese hier jetzt schon eine ganze Zeit mit, da ich auch mit | |
> Datenbanken (allerdings dBase) arbeite und das Zeit-Problem bei | |
> indizierten Datenbanken dort eigentlich nicht kenne, da z.B. in | |
> meiner Anwendung bei 140.000 Datensätzen eines Kunden, die | |
> Fundstelle zeitgleich erfolgt, habe das allerdings nicht in | |
> Das größte Hindernis war bisher die fehlende | |
> Multitasking-Fähigkeit von dBase, zumindest die in Profan. | |
> Aufforderungen, da etwas zu entwickeln, sind ja leider nie | |
> Da gibt es aber eine Lösung, die auf einer dBase | |
> Open-Source-Entwicklung beruht. Die Entwickler haben alle Codes | |
> ins Internet gestellt, Adresse kann ich im Moment nicht finden | |
> aber wieder besorgen, da ich die fertige DLL benutze, die im | |
> Zusammenhang mit einem anderen kommerziellen | |
> Multimedia-Autoren-System von dessen Entwickler als plugin (dll) | |
> kostenlos zur Verfügung gestellt wird. Meine damit erstellten | |
> Programme sind alle seit 2 Jahren kommerziell im Einsatz und | |
> Mehrplatzfähig. Nur pack() verlangt den exklusiven Zugriff. | |
> Der Feldumfang ist gegenüber dBaseIII wesentlich erweitert und | |
> umfaßt z.B. auch Währungen, largeIntegers und Bilder(!) in | |
> Feldern. Befehle für Tabellen und Reportings liefern | |
> professionelles Design inkl. Steuerbuttons. Die Ergebnisse sind | |
> sprachunabhängig, wenn auch vom Programmierumfeld alles in Englisch ist. | |
> Der Befehlsumfang dieser DLL (432 kB) ist enorm - lege die | |
> Überschriften mal bei - und die Schnelligkeit der Index-Suche | |
> mit/ohne Query-Befehl auch für kommerzielle Anwendungen optimal. | |
> Aber vielleicht trifft das ja auch nicht Deine Zielsetzung und | |
> Deinen Ehrgeiz, etwas Neues zu entwickeln ... | |
> Also vielleicht ist dieser OpenSourceCode von Interesse (die DLL | |
> ist für Profan nicht zu gebrauchen!) Wenn gewünscht, besorge ich | |
> die Adresse aus USA ... | |
> ____________________________________________________ | |
> This section contains descriptions of each of the Action commands | |
> dbfSetImportExportOptions | |
> dbfSetDeleteConfirmation | |
> dbfClearHeadersAndFooters | |
> Um sich von dieser Gruppe abzumelden, klicken Sie bitte hier: | |
mid=31295867&sig=BKAEBLCEPJPJPEMP | |
Die Nutzung von domeus unterliegt den AGB der eCircle AG: | |
https://www.domeus.de/info/terms.jsp , | |
die Sie durch weiteren Erhalt von eMails durch domeus akzeptieren. | |
|
|
|
| |
|
|
|
| RGH meint:
Christian Roosen-Runge schrieb: | |
> die DLL ist für Profan nicht zu gebrauchen! | |
Wenn es an falschen Calling-Conventions liegt (XProfan kennt leider nur | |
den Windows-Standard), könnte ein Wrapper-DLL Abhilfe schaffen. | |
|
|
|
| |
|
|
|
| Wrapper.dll -> dann lieber per InlineAsm... |
|
|
| |
|
|
|
| t-online.rainer_berg meint:
> ich lese hier jetzt schon eine ganze Zeit mit, da ich auch mit Datenbanken (allerdings dBase) arbeite und das Zeit-Problem bei indizierten Datenbanken dort eigentlich nicht kenne, da z.B. in meiner Anwendung bei 140.000 Datensätzen eines Kunden, die Fundstelle zeitgleich erfolgt, habe das allerdings nicht in millisek. gemessen. | |
> Das größte Hindernis war bisher die fehlende Multitasking-Fähigkeitvon dBase, zumindest die in Profan. Aufforderungen, da etwas zu entwickeln, sind ja leider nie umgesetzt worden. | |
... ich bin da noch dran, habe jedoch zwischenzeitlich Assembler | |
gelernt, da ich bei der Einpflegung der Indizes auf Tempoprobleme | |
gestoßen bin. Multiuserfähig ist die DLL jedoch bereits. | |
Um sich von dieser Gruppe abzumelden, klicken Sie bitte hier: | |
Die Nutzung von domeus unterliegt den AGB der eCircle AG: [...] , | |
die Sie durch weiteren Erhalt von eMails durch domeus akzeptieren. | |
ich bin da noch dran, habe jedoch zwischenzeitlich | |
Assembler gelernt, da ich bei der Einpflegung der Indizes auf | |
gestoßen bin. Multiuserfähig ist die DLL jedoch bereits. | |
|
|
|
| |
|
|
|
| |
|
| |
|
|