QT 4.5 containers vom Type "QReadWriteLock" (linux)

[phlox81]

l'abra d'or schrieb:

Die Lösung ist eigentlich recht leicht:
Wenn du tatsächlich mehrere QReadWriteLocks (oder QMutex) in einer Liste ablegen willst, machst du das mit Pointern. Da wird beim Einfügen keine Kopie des Objekts durchgeführt, sondern nur die eines Pointers, und dafür braucht man keinen Kopierkonstruktor/op=.

Was du damit allerdings bezwecken willst weiß ich nicht so ganz.
Und synchronisiert sind die Zugriffe auf den Vector auch nicht, da hab ich keine Ahnung wie das Programm reagiert.

In dem gezeigten Beispiel wäre aber auch dass sinnlos, weil die Instanz ja nach dem Methoden Aufruf nicht mehr existiert.
Der Sinn der ganzen Sache überhaupt würde mich aber auch interessieren

[Gast]

Hi,

der Sinn ist eigentlich ebenso einfach.

Es werden aus mehreren Threads auf einen Datenbereich zugegriffen. Bis jetzt hatte ich das Locking ausserhalb der Klasse durchgeführt, will es aber jetzt in die Klasse übernehmen.

Der Lock ist so gestaltet, das mehrere Thread den Datenbereich gleichzeitig lesen dürfen, aber nur einer Schreiben darf.

Daher die besagt Klasse, welche das eigentlich sehr gut steuert.

Gruss R.

P.S.: Vorher war es übrigens ein globales Array von dieser Klasse.

[l'abra d'or]

Du verstehst uns falsch! Es geht nicht um den Sinn des Lockings an sich, sondern warum du unbedingt die ganzen Locker in einer Liste abspeichern musst! Bringt doch nix, vor allem wenn du eh Klassen hast, dann hau den Mutex/ReadWriteLock doch als Member in die Klasse.
Du willst ja die Member dieser Klasse schützen, und nicht irgendwelche! Wenn du einen Lock in eine Funktion einbaust und in einer anderen unabhängigen auch mit diesem Lock arbeiten willst blockieren die sich ja unsinnigerweise gegenseitig.

Oder warum müssen die alle in eine Liste? Und wir reden hier schon von den Locks die in eine Liste kommen und nicht von eigenen Klassen? Wenn doch -> eigener Kopier-Konstruktor/Zuweisungsoperator, der eben den Lock nicht kopiert sondern neu erstellt.

[Gast]

Denn Ansatz hatte ich schon mal,
ich werde diese Idee nochmals aufnehmen, da sie mir logisch erscheint. Schliesslich ist das "locken" ja eine Eigenschaft die sich auf die jeweilige Datenblock Klasse bezieht.

Danke

[Gast]

Ach ja,

jetzt fällt mir wieder ein, warum ich das Teil nicht in
meine Datenblock Klasse anlegen kann.

Q_DISABLE_COPY(QReadWriteLock)

Die Klasse wird dynamisch angelegt.

Das geht ja nun mal nicht. Und jede Instanz der Klasse benötigt einen eigenen Lock, da der Zugriff auf verschiedene Instanzen "gleichzeitig" statt finden kann.

Gruss

[l'abra d'or]

Wo ist dabei das Problem?
Wie gesagt, eigener Copy-CTor und op=, der alle Member kopiert, nur halt den Lock nicht. Da gibt es ja nix zu initialisieren.

[Gast]

Hi,

Und jede Instanz der Klasse benötigt einen eigenen Lock, da der Zugriff auf verschiedene Instanzen "gleichzeitig" statt finden kann.

Es wird gleichzeitig auf mehrere Datenbereiche zugegriffen,
da benötigt jeder Datenbereich seinen eigenen Lock.

Einer für alle geht da nicht .

Oder wie meinst Du das ?

Gruss

[l'abra d'or]

Ritchie schrieb:

Es wird gleichzeitig auf mehrere Datenbereiche zugegriffen,
da benötigt jeder Datenbereich seinen eigenen Lock.

Einer für alle geht da nicht .

Oder wie meinst Du das ?

Gruss Ritchie

Kannst du ein konkretes Beispiel liefern, wie du dir das gedacht hast?
Ich nehme ja an, du willst sowas:

class Test
{
    QString m_string;
    int m_counter;
    QReadWriteLock stringLock;
    QReadWriteLock counterLock;
    ///usw.
};

Oder sehe ich das falsch?
Und willst du diese beiden Locks jetzt in ne Liste pushen? Oder war das für Klassen-ungebundene Locks?
Wie gesagt: konkretes Beispiel und mankann mehr sagen.

Grüßle

[Gast]

Nein,

ich habe eine Klassen,

class Test
{
    QString m_string;
    int m_counter;
    ///usw.
};

welche über eine zweite Klasse zu einer Collection

class Tests
{
     ....
    Test    *find( QString );
    ....
    private:
vector<Test>    TextEntries;	
    ///usw.
};

Das Laden der Collection erfolgt über eine externe Datei, damit die
Information beliebig erweitert werden können.

Hierbei wird "Test" immer dynamisch angelegt und kann somit kein
QReadWriteLock beinhalten.

Derzeit versuche ich es mit einem static von QReadWriteLock [255] in der
Klasse Tests. Hier habe ich nur den Nachteil, das eine zahlenmäßige
Begrenzung der Element vorhanden ist.
Ebenso die Resourcenverschwendung, wenn ich nur zwei Element lade.

Gruss

[phlox81]

Hallo, sag mal weisst du was du da tust?
Verstehst du überhaupt was von C++?

Es wurde dir doch schon gesagt, das die Klasse einen eigenen Copy Construktor braucht, damit sie kopierbar ist, auch wenn sie nicht kopierbare Elemente enthält.
Lerne bitte erstmal die fundamentalen Grundlagen von C++ bevor du mit GUI und Multithreading anfängst!

[Gast]

Mach ich.

Nur nicht mehr hier

Gruss