OO und MultiThreaded

Hallo

wie kombiniert ihr Synchronisationsprimitiven mit euren Klassen? Nutzen die Klassen selbst ihre eigenen Synchronisationsprimitiven oder bieten sie dem Nutzer Funktionalitäten an, die Synchronisationsprimitiven explizit zu nutzen?

Das Problem dahinter ist:

In meinen Augen reicht es nicht, wenn ich innerhalb einer Klasse am Anfang jeder Member-Funktion ein entsprechenden Lock-Objekt erstelle. Oft muss IMO in einen übergeordneten Kontext gelockt werden. Auf der anderen Seite ist das ziemlich fehlerlastig, da nicht jeder Nutzer konsequent die Synchronisationsprimitiven nutzt.

class A
{
private:
   //...

public:
   int get()
   {
       //Lock, mach was, return
   }

   void set(int)
   {
       //Lock, mach was, return
   }
}

//...
A a;
a.set(a.get()+1); //Das geht so nicht!
//...

Hier wäre eher etwas in dieser Art angebracht:

//...
A a;
a.get_lock(),a.set(a.get()+1); //Das geht so!
//...

Danke für eure Meinungen!

byto

So:

public synchronized int get() { ... };
public synchronized void set(int a) { ... };

byto schrieb:

So:

public synchronized int get() { ... };
public synchronized void set(int a) { ... };

Das ist schlecht, man soll nicht auf this synchronisieren.

rapso

genau wie OOP ist multithreading etwas was vom design abhaengt. nur weil jemand ne class benutzt ist es noch lange nicht OOP, und nur weil jemand threads benutzt, ist die applikation noch lange nicht multithreaded. wenn ueberall seriell daten gefuettert wird, hast du nur ne ausgefallene art ein programm auszufuehren.

in set/get zu pauschal zu synchronisieren ist genau so sinnvoll wie fuer jede variable die man nutzen wird eine eigene klasse abzuleiten.

hustbaer

In meinen Augen reicht es nicht, wenn ich innerhalb einer Klasse am Anfang jeder Member-Funktion ein entsprechenden Lock-Objekt erstelle.

Korrekt.

Oft muss IMO in einen übergeordneten Kontext gelockt werden.

Rrrrrrrüchtüüüüg.

Auf der anderen Seite ist das ziemlich fehlerlastig, da nicht jeder Nutzer konsequent die Synchronisationsprimitiven nutzt.

Das Leben ist hart.

hustbaer schrieb:

In meinen Augen reicht es nicht, wenn ich innerhalb einer Klasse am Anfang jeder Member-Funktion ein entsprechenden Lock-Objekt erstelle.

Korrekt.

Oft muss IMO in einen übergeordneten Kontext gelockt werden.

Rrrrrrrüchtüüüüg.

Auf der anderen Seite ist das ziemlich fehlerlastig, da nicht jeder Nutzer konsequent die Synchronisationsprimitiven nutzt.

Das Leben ist hart.

OT: LichtTools made my day!