Multithread NullPointerException verhindern

[virtualAudio]

Hi Leute,

ich hab eine Prinzipfrage, kein konkretes Beispiel.

Was passiert denn wenn ich sowas hab wie

if(lockObject!=null){
  // ....hier....
  synchronized(lockObject){
  }
}

das lockObject bei "...hier..." NULL wird?

Müsste ich um sowas zu verhindern so einen Synchronized block in einen try-Block reinschreiben und eine Nullpointerexception abfangen?

Also prinzipiell gehen ja zwei Sachen auf jeden Fall. Entweder ich hab meine Threads und was sie wann tun gut durchgedacht und kann sowas auf anderem Wege verhindern, zB indem ich die Stelle an der das lockObj. NULL werden kann auf keinen Fall aufrufe solange ein Thread noch an so einen synchronized Block wie hier stoßen kann, oder ich kann eben die Exception abfangen.

Ich schreibe hier weil ich mir ersteres bei komplizierten Programmen nicht so richtig vorstellen kann (da fehlt mir die multithread Erfahrung und weil mir zweiteres nicht wie der beste Weg vorkommt).

Hat dazu jemand eine Idee/Meinung bzw. einen Standardweg der üblich ist um sowas zu verhindern und der von meinen beiden ideen abweicht?

lg andi

 

[Chumax]

Nimm als lockObject ein anderes das nicht auf Null gesetzt wird.

 

[Gast2]

public class Test
{
    private Object myLockObject = new Object()

    // ... bla ...

    public void foo()
    {
        synchronized(myLockObject)
        {
        }
    }
}

 

[virtualAudio]

Nimm als lockObject ein anderes das nicht auf Null gesetzt wird.

Logisch...das wird wohl der richtigste Weg sein wenn man glaubt, dass das passieren könnte

Danke!

 

[Andi_CH]

NEIN! Das ist Grundfalsch! -> Siehe weiter unten.

Gibt es in Java wirklich keine atomaren Instruktionen? (Testen und setzen in einem Maschinenzyklus)
Falls es das wirklich nicht gibt, wird ein Java Programm niemals 100% sicher funktionieren.

Das mit dem anderen Objekt verwenden war ja wohl nicht ernst zu nehmen, oder?

Es geht um einen kritischen Bereich der von 2 Threads durchlaufen wird - willst du jedem Thread ein eigenes Lock-Objekt geben ???:L Denke mal darüber nach ob das funktionieren kann (Nein, kann es nicht) es MUSS ein gemeinsames Objekt sein!

Thread1 kommt in den kritischen Bereich, prüft das Objekt und lockt es
Thread2 kommt in den kritischen Bereich und prüft sein eigenes Objekt -> Schei......

Thread2 kommt in den kritischen Bereich und prüft das gmeinsame Objekt -> ok -> er muss warten.

Problem:
Thread1 kommt in den kritischen Bereich, prüft das Objekt und wird unterbrochen
Thread2 kommt in den kritischen Bereich, prüft das Objekt, lockt es, bearbeitet den kritischen Bereich
und wird unterbrochen.
Thread1 wird aktiviert-lockt das Objekt und bearbeitet den kritischen Bereich -> PROBLEM!

Ergo: So kann es unmöglich funktionieren - es muss eine unteilbare Anweisung geben - prüfen und locken in einem, sonst ........

 

[FArt]

NEIN! Das ist Grundfalsch!

Was genau?

Gibt es in Java wirklich keine atomaren Instruktionen? (Testen und setzen in einem Maschinenzyklus)

The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 133

Das mit dem anderen Objekt verwenden war ja wohl nicht ernst zu nehmen, oder?

Thread1 kommt in den kritischen Bereich, prüft das Objekt und lockt es
Thread2 kommt in den kritischen Bereich und prüft sein eigenes Objekt -> Schei......

Doch, natürlich. Das heißt nicht, dass man für jeden Thread ein anderes Objekt verwendet sondern einfach für die kritischen Sektionen, die über den gleichen Monitor gehen. Kommen diese Sektionen in nur einer Klasse vor, kann das ein Member der Klasse sein.
Du schmeißt hier Thread und Objekt in einen Topf.

 

[Andi_CH]

Logisch...das wird wohl der richtigste Weg sein wenn man glaubt, dass das passieren könnte

Danke!

Diese Überlegung ist falsch - dann funktioniert das Locking nicht - es muss immer ein gemeinsames Objekt sein, dass für das Locking verantwortlich ist.


Und mit "Objekt" habe ich das Lock-Objekt gemeint --- das muss gemeinsam sein und somit bleibt das Risiko, dass einer der Thrads die Referenz auf dieses auf null setzt.

 

[bygones]

Du schmeißt hier Thread und Objekt in einen Topf.

this

Objektmonitore sind dennoch out of the art.... -> Lock (Java Platform SE 6)

 

[Andi_CH]

Vielleicht hätte ich besser von Lock-Variable gesprochen ....