Webserveranwendung: EXE ruft ISAPI

[Delbor]

Hi Sir Rufo

Laut Help gilt das mit der falschen Sicherheit für CriticalSections ebenso wie für Synchronize. Ich denke mir, eine CriticalSection beim Create des Threads und bestücken seiner Felder sollte ausreichen, da der Thread zu seiner Laufzeit nur auf seinen eigenen Speicherbereich zugreift.

Gruss
Delbor

[Sir Rufo]

Wenn du bei einem Thread von aussen die Felder bestücken kannst, dann hast du den Thread absolut falsch aufgebaut.

Von aussen sollte man mit dem Thread ausschliesslich über Methoden und Eigenschaften kommunizieren können. Diese kann man zuverlässig mit den SynchroObjekten threadsafe gestalten.

Eigentlich ist es ganz einfach: Man sorgt dafür, dass es nicht möglich ist auf einen Speicherbereich mit unterschiedlichen Threads gleichzeitig zuzugreifen.

Wenn man das mit Synchronize versucht (im MainThreadKontext), dann muss man höllisch aufpassen, dass jeder Zugriff darauf per Synchronize erfolgt (hört sich irgendwie schon komisch an).

Zitat von Delbor:

... eine CriticalSection beim Create des Threads und bestücken seiner Felder sollte ausreichen, da der Thread zu seiner Laufzeit nur auf seinen eigenen Speicherbereich zugreift.

hmmm, wenn du innerhalb des Konstruktors die Felder setzt und auf die von aussen (über Eigenschaften, Methoden) nicht zugegriffen wird, dann brauchst du gar keine CriticalSection.

[Olli73]

Zitat von Delbor:

Hi Sir Rufo
Ich denke mir, eine CriticalSection beim Create des Threads und bestücken seiner Felder sollte ausreichen, da der Thread zu seiner Laufzeit nur auf seinen eigenen Speicherbereich zugreift.

2 "Denkfehler" in 1 Satz:

(1) Der Thread hat keinen "eigenen Speicherbereich", es gibt nur 1 gemeinsamen Speicherbereich für den gesamten Prozess; das "getrennt" zu halten bzw. gegenseitige Zugriffe in sicherer Weise zu erlauben ist deine Aufgabe.

(2) Die CriticalSection musst du vor jedem Zugriff betreten und anschließend wieder verlassen und zwar aus dem Thread heraus, der auf die Daten zugreifen will; so wird der gleichzeitige Zugriff von 2 Threads aus verhindert. Das ist aber auch der Grund, warum die CriticalSection dir bei GUI-Komponenten nichts bringt: Da die VCL/WinApi deine CriticalSection nicht kennt, wird sie sie auch nicht beachten.

[Sir Rufo]

Zitat von Olli73:

Das ist aber auch der Grund, warum die CriticalSection dir bei GUI-Komponenten nichts bringt: Da die VCL/WinApi deine CriticalSection nicht kennt, wird sie sie auch nicht beachten.

Ähm, nee, das ist anders.

Die VCL ist nicht threadsafe ausgelegt und darum darf man auf die VCL-Teile eben nur synchronisiert zugreifen. Der andere Weg ist doch simpel über Getter und Setter zu erreichen, die dann die CriticalSection betreten und wieder verlassen.

Irgendwie beschleicht mich das Gefühl, dass hier von einer globalen CriticalSection gesprochen wird ... ist dem so, oder kommt nur meine Paranoia wieder hoch?

[Olli73]

Zitat von Sir Rufo:

Zitat von Olli73:

Das ist aber auch der Grund, warum die CriticalSection dir bei GUI-Komponenten nichts bringt: Da die VCL/WinApi deine CriticalSection nicht kennt, wird sie sie auch nicht beachten.

Ähm, nee, das ist anders.

Die VCL ist nicht threadsafe ausgelegt und darum darf man auf die VCL-Teile eben nur synchronisiert zugreifen. Der andere Weg ist doch simpel über Getter und Setter zu erreichen, die dann die CriticalSection betreten und wieder verlassen.

Ich habe mich da falsch ausgedrückt; ich meinte eigentlich, das es nicht ausreicht, wenn man jetzt auf den Gedanken kommt einfach selbst immer vor einem Zugriff auf ein VCL-Objekt eine CriticalSection zu betreten. Dann wären zwar die eigenen Zugriffe abgesichert, aber nicht die von der VCL/WinAPI...

Zitat:

Irgendwie beschleicht mich das Gefühl, dass hier von einer globalen CriticalSection gesprochen wird ... ist dem so, oder kommt nur meine Paranoia wieder hoch?

Also ich spreche die ganze Zeit nur von einer CriticalSection für eine "SessionList" und ggf. je einer CriticalSection pro "Datenobjekt" (welches in dieser Liste verwaltet wird).

[Delbor]

Hi zusammen

Ich sehe das bisher so vor :

1. Die Anfrage kommt rein
2. Sie wird analysirtte
3. In der Sessionlist wird geprüft, ob für den Anfrager bereits eine Session Existiert. Ein Datenbankzugriff ist hier nicht nötig, da die DB nur Infos über geschlossene Sessions enthält.
4. Gibt es keine Session, wird eine neu erstellt - auchh für anonyme User.
5. Gemäss der Anfrage wird die DB abgefragt. Die enthält u.a. Felder zum

   • URL
   • HTML
   • CSS
   • MenueCSS

6. Das Resultat wird an Klassenfelder verteilt, die den Tabellenfeldern entsprechen. Diese Klasse Marke Eigenbau ist ein Proberty einer eigenen Threadklasse
7. Der Thread wird erstellt und die Isapi gestartet

Zitat:

(2) Die CriticalSection musst du vor jedem Zugriff betreten und anschließend wieder verlassen und zwar aus dem Thread heraus, der auf die Daten zugreifen will;

Wenn eine CriticalSection 'nur' den Datenbereich sperrt, auf die der Thread, der sie einsetzt, zugreifen will, brauchts wirklich keine, immer vorausgesetzt, die Parameter Requestinfo, ResponseInfo und Co. haben keine Verbindung nach aussen und sind eigene Instanzen der jeweilgen Klassen.

Gruss
Delbor

[Olli73]

Zitat von Delbor:

Wenn eine CriticalSection 'nur' den Datenbereich sperrt, auf die der Thread, der sie einsetzt, zugreifen will, brauchts wirklich keine, immer vorausgesetzt, die Parameter Requestinfo, ResponseInfo und Co. haben keine Verbindung nach aussen und sind eigene Instanzen der jeweilgen Klassen.

Wenn sichergestellt ist, dass es keine Überschneidungen bei den Zugriffen durch die Threads gibt, braucht man natürlich nix abzusichern.


Aber dass bei Verwendung von TIdHttpServer, TIdHttpWebBrokerBridge etc. bereits "automatisch" mehrere Threads existieren, ist dir bewusst?

Gruß,
Olli

[Delbor]

Hi Olli

Heute morgen ist es mir wie Schuppen von den Augen gefallen: Der Parameter IdContext ist vom Typ AThread, und der wird bei den Sockets das erste mal deklariert und dann an alle Nachkommen weitergereicht, damit diese eine CriticalSection für den existierenden Thread einrichten können.
Pro Anfrage existiert also genau ein Thread, und zwar genau so lange, bis dieser die Antwort über die Sockets ausgegeben hat. Natürlich kann es trotzdem zu Überschneidungen kommen; nämlich dann, wenn kurz nacheinander mehrere Threads gestartet werden, aber einer (oder mehrere) schneller arbeitet als andere.
Wenn dann die Anfrage beim Webmodul angekommen ist, ist ein Speicherzugriff ohne Criticalsection nicht mehr möglich, bzw. ein Hazzardspiel. Und das bedeutet, dass mein Konzept, dem Thread alle Infos beim Start mitzugeben, hier nicht möglich ist.

Zitat:

Aber dass bei Verwendung von TIdHttpServer, TIdHttpWebBrokerBridge etc. bereits "automatisch" mehrere Threads existieren, ist dir bewusst?

Sorry, das suggeriert eigentlich, das alle diese Klassen einen Thread einführen. Dabei übernehmen sie nur den einen (pro Aufruf) von ihrem Vorfahren im Parameter IdContext.

Gruss
Delbor

[Olli73]

Zitat von Delbor:

Und das bedeutet, dass mein Konzept, dem Thread alle Infos beim Start mitzugeben, hier nicht möglich ist.

Das ist es, was ich die ganze Zeit versuche zu erklären...

Deshalb solltest du einfach eine DLL (oder EXE) verwenden und dir dort eine eigene Session-Verwaltung (mit CriticalSections !) einbauen.

Gru0,
Olli