ASP.Net / Multithreading

hi,

ich habe eine theoretische Frage für das Verständnis: im Prinzip ist jede ASP.Net-Anwendung doch eine Multithreading-Anwendung. Zwar nicht im Sinne von Threads mit er Thread-Klasse aber viele Benutzer können eine Website gleichzeitig aufrufen.

Habe ich nun ein Portal, in dem User die gleichen Daten ändern können, muss ich mich also um kritische Codeabschnitte kümmern... oder?

Wäre es richtig, an dieser Ecke mit Semaphoren zu Arbeiten oder gibt es hier andere Vorgehensweisen?

Viele Grüße,
xforfun

wenn du die daten im sql server speicherst, kümmert er sich selbst um diese synchronization. sonst musst du es selber implementieren. z.B. google nach c#+remoting+singleton.

Naja ich würde dir nicht raten das x User an dem gleichen kontent arbeiten ..
das wäre so nach dem motto "Wer zuletzt kommt, mahlt zuerst" also der der am ende speichern klickt hat das vorrecht..

Zu deiner ersten Frage... es gibt einrn ThreadPool der stück für stück abgearbeitet wird vom IIS schau mal unter "QueueUserWorkItem"...

ich benutze den z.B. um emails zu versenden das kann man auch in einer normalen aspx mit den tag Async="true" aber in einem UserControl geht das nicht da müsste man den Pool benutzen wenn die seite nicht einfrieren soll ^^

 private void SendMail(System.Net.Mail.MailMessage message)
        {
          ThreadPool.QueueUserWorkItem(new WaitCallback(SendAsync), message);
        }

        private void SendAsync(object state)
        {
            try
            {
                System.Net.Mail.MailMessage message = (System.Net.Mail.MailMessage)state;
                System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient();
                client.Send(message);
            }
            catch(Exception ex)
            {
                //throw new Exception(ex.Message);
            }
        }

vieleicht hilf Dir das weiter...

.elron

nachteil des TheadPools ist beschränkung auf eine maximale thread-anzahl. vielleicht man kann es durch konfiguration vergrößern.

jetzt ist mir aufgefallen - du brauchst kein remoting, speichern kann stink normal statt finden, beim speichern musst du nur Mutex verwenden. so bald ein aktueller thread den mutex besitzt kann er speichern, die anderen müssen in einer schlange warten. danach wird der mutex freigegeben und der nächste thread kann ihn übernehmen und speichern (thread synchronisierung)

Ja, mittels Technologien wie IIS und ASP.NET zieht die parallele Verarbeitung gewissermaßen durch die Hintertür ein. Und auch die damit verbundenen Probleme.

Du musst auf jeden Fall davon ausgehen, dass ein Codeabschnitt mehrfach ausgeführt wird - zur selben Zeit. Normalerweise ist das kein Problem, weil der meiste Code schon deswegen threadsicher ist, weil nur lokale Variablen verwendet werden und außer des SQL-Server keine weiteren zentralen Ressourcen genutzt werden.

Problematisch wird es, wenn du beispielsweise mit statischen Variablen arbeitest, zum Beispiel im Zusammenhang mit einigen OR-Mappern. Dafür gibt es dann Möglichkeiten der Synchronisierung, auch in ASP.NET und auch zahlreich .NET Sprachkonstrukte, zum Beispiel das [ThreadStatic]-Attribut.

Auch der Datenbankzugriff kann Probleme bereiten, je nach eingestelltem IsolationLevel, der Art des Zugriffs, der Menge der abgerufenen und verarbeiteten Daten sowie eventuell vorhandenen Transaktionen.

Meines Erachtens lohnt es sich daher immer, das im Hinterkopf zu behalten, gerade bei schwer zu lokalisierenden Fehlern.

Ein weiterer Nachteil ist es, dass nach Start der Threads die Einflussmöglichkeiten gering sind, wenn beispielsweise ein anderer Thread darauf warten möchte, bis alle Aktionen beendet sind, außerdem wird ein "Vordergrund-Thread" benötigt.

Eine Einflussmöglichkeiten besteht mittels SetMinThreads und SetMaxThreads.

Warum für solche Aufgaben nicht einfach einen Service schreiben und das Multitasking der Laufzeitumgebung überlassen, die dann dafür konfiguriert werden kann?

Hallo zusammen,

die konkrete Frage, die sich mir stellt ist die: Welche Daten werden "zeitgleich" verändert.

Wenn es sich ausschließlich um Datenbank-Daten handelt, so kann man dort sehr einfach mittels Transaktionen und deren Levels eine Synchronisation erreichen ohne dass man großartig im Quellcode etwas berücksichtigen müsste (mal Fehlerbehandlung im Transaktionsfehlerfall abgesehen).

Wenn es sich um .NET Daten handelt (Werte im Speicher in Klassen/Strukturen), so wird man mittels "lock" schon einiges erreichen können. Ein Singleton ist in aller Regel nicht unbedingt vonnöten, kann aber verwendet werden. Wichtiger sind wohl die so genannten "Factories".

Geht es um Daten auf der Platte, dann sollte man sich wirklich Gedanken machen, ob man das nicht anders lösen kann. Das wäre dann extrem unangenehm und wahrscheinlich das komplexeste Szenario.

Grüße
Norman-Timo

VORSICHT: In ASP.NET sollte man NIEMALS den Threadpool verwenden, sondern IMMER entweder über den asynchronen Aufruf von Delegates gehen oder Threads explizit mit Hilfe der Thread-Klasse erzeugen.

Der Grund dafür liegt darin, dass ASP.NET selbst zur Behandlung von einkommenden Requests den ThreadPool nutzt, und man ASP.NET somit Resourcen entzieht, wenn man den selbst nutzt.

Siehe unter anderem hier: http://csharpfeeds.com/post/5415/Dont_use_the_ThreadPool_in_ASP.NET.aspx

Hallo zusammen,

vielen Dank für die reichlichen Antworten. Da ist einiges dabei, über das ich nun nachdenken kann 😃 Ich arbeite derzeit an einer Art Portal. Es gibt einige Stellen bei denen ich mir unsicher bin, wenn mehrere User gleichzeitig klicken, was dann passieren würde bzw, dass es da wahrscheinlich knallt.

Hallo zusammen,
Geht es um Daten auf der Platte, dann sollte man sich wirklich Gedanken machen, ob man das nicht anders lösen kann. Das wäre dann extrem unangenehm und wahrscheinlich das komplexeste Szenario.

Es gibt Stellen, da arbeite ich mit Bildern auf der HDD.

Du musst auf jeden Fall davon ausgehen, dass ein Codeabschnitt mehrfach ausgeführt wird - zur selben Zeit. Normalerweise ist das kein Problem, weil der meiste Code schon deswegen threadsicher ist, weil nur lokale Variablen verwendet werden und außer des SQL-Server keine weiteren zentralen Ressourcen genutzt werden.

Der SQL-Server ist eine zentrale Ressource, die ich nutze. Es gibt noch ein paar wenige Objekte, die static laufen und die Verwaltung betreffen. Die müsste ich auch noch mal prüfen.

An Mutex hatte ich bereits auch gedacht. In diese Richtung werde ich vielleicht mal weiterdenken. Vielen Dank 😃

mfg
xforfun

Hallo xforfun,

Es gibt Stellen, da arbeite ich mit Bildern auf der HDD.

So lange es nur lesend ist, dann kann man beim Öffnen darauf achten, dass es nur lesend geöffnet wird, da sollte es keine Schwierigkeiten geben.

Wenn es auch schreibend (bearbeitend) ist, dann sollte hier ein lock ausreichen, hier würde ich ein lock-Objekt nehmen, das den eindeutigen voll qualifizierten Dateinamen enthält, das ist eindeutig.

Oft ist Mutex zu hoch gegriffen, kann aber sein, dass es in Deinem Anwendungsfall Sinn macht, das kann ich so aus der Ferne nicht beurteilen.

Grüße
Norman-Timo