SQLite und mehrere Threads

[ColonelMoW]

Hat schonmal jemand versucht eine einzige SQLite Datenbank in mehreren Threads zu oeffen und zu bearbeiten? Eigentlich sollte das doch funktionieren.
Jedenfalls steht unter http://www.sqlite.org/faq.html#q6 :
"SQLite is threadsafe"

Aber es steht auch da, dass Threads boese sind.... das schuechtert mich irgendwie ein...
Hat damit jemand Erfahrung?

Col

[RHBaum]

Threads sind böse !!!

Threadsicher bei ner lib bedeutet ned viel. Bedeutet fuer dich nur, das du dein Multithreadprogramm technisch korrekt absichern kannst, und nicht das es zu "ungeahnten" seiteneffekten zwischen den threads kommt.

Die threads absichern muss scho selber

Also ran ans werk ....

mit sqlite hab ich noch ned viel gemacht ....


Ciao ....

[Deever]

Threads sind böse !!!

Nein.
Threads sind Threads.

Threadsicher bei ner lib bedeutet ned viel.

"Threadsicher" heißt wie überall auch bei Libraries genau "threadsicher", nicht mehr und nicht weniger. Sqlite stellt genau um thread safety anzubieten die sqlite3 struct zur Verfügung, sonst bräuchte es eine solche gar nicht. Wer dann diese struct in mehreren Threads benutzt, ist selber schuld.

Die threads absichern muss scho selber

Du meinst, den multithreaded code absichern.

SCNR,
/dev

[ColonelMoW]

hmmm...
Was haltet ihr von dieser Loesung:
Es gibt zwei Threads: GUI-Thread und Worker-Thread.
Der Worker-Thread hat ein Objekt, welches die Verbindung zur SQLite-Datenbank aufbaut. Moechte der GUI-Thread nun einen Datensatz aus
der Datenbank haben, schickt er ein Signal an das Objekt im Worker-Thread. Dieses antwortet dann wiederum mit einem Signal (beide Threads haben eigene Event-Loops).
Problem ist nur, wenn der GUI-Thread sehr viel aus der Datenbank braucht...
Hat jemand Erfahrung wie schnell so eine Anfrage ist?

Oder hat vielleicht jemand einen besseren Vorschlag? Das Problem ist ja, dass der GUI-Thread keine direkten Anfragen an die Datenbank stellen darf...

Col

[ColonelMoW]

Oder was waere wenn ich sowohl im GUI-Thread als auch im Worker-Thread jeweils eine eigene Verbindung zur SQLite-Datenbank herstelle?
Jede Anfrage wird dann mit einem QMutex gesichert, so dass immer nur ein Thread zur gleichen Zeit Anfragen an die Datebank stellen darf...
Das waere doch Performance-technisch besser, oder?

Col

[RHBaum]

Du meinst, den multithreaded code absichern.

Einige verstehen unter multithraeding safe was ganz falsches
z.b. sind fast alle STL Impls multithreadingsicher. Und Einige denken dass dann z.b. nen gleichzeitiger insert von 2 Threads in die selbe list abgesichert wird.

Oder was waere wenn ich sowohl im GUI-Thread als auch im Worker-Thread jeweils eine eigene Verbindung zur SQLite-Datenbank herstelle?

Möglich, sicher, schoen ? glaub nicht.

Zumal du paar vorteile von dem multithreading verschenkst .....

zb, dein worker thread macht mas langwieriges ... deine GUI thread will was kurzes machen, aber der workerthread blockiert ihn ueber nen mutex = deine oberflaeche haengt, trotz multithreading ....

Performance ist bei MT eher das secundaeres thema ... es sei denn du willst gezielt auf mehrkernarchitekturen optimieren, da hilft dir Multithreading allein aber auch ned weiter, iss aber ne vorraussetzung fuer .

Gui thread immer kurze sachen machen lassen ....
Optimaler sind meist so konzepte ala:
dein DB Zugriffs-Object hat nen Messagethread
dieser liest "Anfragen" aus ner Liste(gemutext) und startet dafuer nen extra workerthread und laesst dem die anfrage abarbeiten, legt das ergebniss an nen definierten ort ab, wenn der fertig ist, schreibt der ne benachrichtigung und beendet sich ...
der Guithread fragt regelamessigen abstaenden ab, ob ne anfrage fertig ist (OnTimer Event)... oder man arbeitet direkt mit signal/slot gleich (seit QT4) und laesst sich von der internen Msgqueue (GUI Thread) von QT direkt benachrichten ...

Wie gesagt kommt immer auf die anwendung draufan ... was man braucht und wie sinnvoll sowas komplexes ist ....

feur 90% langt meist ne singelthreadanwendung.
fuer 9 % langt meist ein workerthread, der immer nur eine anfrage parallel zum Guithread abarbeitet (denen gehts meistens nur darum, die gui ned zu blockieren)
Und 1% braucht wirklich mehrere workerthreads parallel ... wegens der performance

Ciao ...

[ColonelMoW]

@RHBaum
Das mit der Liste im Shared Memory finde ich sehr gut... ich glaube das werde ich mal versuchen. Vielen Dank!

hast du dir das selbst ausgedacht?

Col

[qt2007]

Hab schon mal nach SQLite in mehreren Thread geforscht. Hier vielleicht ein interessanter link: http://www.linuxjournal.com/article/9602
Allerdings mit Vorsicht zu geniessen mein ich, meiner Meinung nach sind da auch ein paar Fehler drin.

[RHBaum]

hast du dir das selbst ausgedacht?

Neeeee

Wenn man ne weile programmiert, kennt man eh so bissi die "standard implementationen" .... meist orientiert man sich zuerst an anderen.
Zu MT gibts auch paar gute Buecher, wo so sowas beschrieben wird ... man musses meist natuerlich noch auf die eigene Umgebung (in dem falle QT und die eigene App ummuenzen).

Selbst ausdenken iss eh eher kritisch.
Es gibt fuer fast alle probleme schon ne Loesung Man muss sie eigentlich nur finden, und geeignet adaptieren koennen. Das ist eigentlich auch die hauptaufgabe des Programmieres ... vorhandene Loesungen analysieren, Vor- Nachteile abwaegen ... anpassen ... testen. Das innovative ist eigentlich eher so standardloesungen geeignet zu kombinieren.
Pfiffige Ideen ham einen Nachteil: Es ist schwer zu umschreiben, was genau da gemacht wurde, und ned jeder versteht das gleich -> schwer zu warten.
Im gegensatz zu standard loesungen, da langen meist eh paar schlagwoerter, und der Programmierer nach Dir (sollte) weiss um was es geht ....

Ciao ....