Tue “nichts” während “Bedingung”

Beim Durchsuchen des Codes für die Java 8-Version von ForkJoinPool (die einige interessante Änderungen gegenüber Java 7 aufweist) bin ich auf dieses Konstrukt gestoßen (hier):

do {} while (!blocker.isReleasable() &&
             !blocker.block());

Ich kämpfe damit, warum Sie es so schreiben würden, anstatt nur

while (!blocker.isReleasable() &&
       !blocker.block());

Ist es nur eine Wahl der Semantik/Lesbarkeit, da Sie das erste Konstrukt lesen könnten als do "nothing" while "conditions"? Oder übersehe ich noch einen Zusatznutzen?

Wenn Sie die Kommentare oben in der Datei lesen, gibt es direkt unter der Klassendeklaration einen Abschnitt, der die Verwendung dieses Konstrukts erklärt:

Style notes

===========

[...]

There are several occurrences of the unusual "do {} while
(!cas...)"  which is the simplest way to force an update of a
CAS'ed variable. There are also other coding oddities (including
several unnecessary-looking hoisted null checks) that help
some methods perform reasonably even when interpreted (not
compiled).

ForkJoinPool macht ausgiebigen Gebrauch compareAndSwap... aus sun.misc.Unsafe und die meisten Vorkommen von do {} while (...) in ForkJoinPool kann – wie in anderen Antworten erwähnt – durch diesen Kommentar unter der Überschrift Stilhinweise erklärt werden:

* There are several occurrences of the unusual "do {} while
* (!cas...)"  which is the simplest way to force an update of a
* CAS'ed variable. 

Die Wahl, Write a zu verwenden while-Schleife mit leerem Körper als do {} while (condition) scheint jedoch eine hauptsächlich stilistische Wahl zu sein. Das ist vielleicht klarer in HashMapdas zufällig in Java 8 aktualisiert wurde.

Im Java7 HashMap das kannst du finden:

while (index < t.length && (next = t[index++]) == null)
    ;

Während sich ein Großteil des Codes um ihn herum ebenfalls geändert hat, ist es klar, dass der Ersatz in Java 8 dieser ist:

do {} while (index < t.length && (next = t[index++]) == null);

Die erste Version hat die Schwäche, dass das zufällige Löschen des einsamen Semikolons die Bedeutung des Programms abhängig von der folgenden Zeile ändern würde.

Wie unten zu sehen ist, wird Bytecode generiert von while (...) {} und do {} while (...); ist etwas anders, aber in keiner Weise, die irgendetwas beeinflussen sollte, wenn es ausgeführt wird.

Java-Code:

class WhileTest {
    boolean condition;

    void waitWhile() {
        while(!condition);
    }

    void waitDoWhile() {
        do {} while(!condition);
    }
}

Generierter Code:

class WhileTest {
  boolean condition;

  WhileTest();
    Code:
       0: aload_0       
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return        

  void waitWhile();
    Code:
       0: aload_0       
       1: getfield      #2                  // Field condition:Z
       4: ifne          10
       7: goto          0
      10: return        

  void waitDoWhile();
    Code:
       0: aload_0       
       1: getfield      #2                  // Field condition:Z
       4: ifeq          0
       7: return        
}

Abgesehen von potenziellen Leistungsvorteilen gibt es einen klaren Lesbarkeitsvorteil.

Mit while (X) ; das nachgestellte Semikolon nicht immer auf den ersten Blick ersichtlich ist, könnten Sie irrtümlich glauben, dass sich die folgende(n) Anweisung(en) innerhalb der Schleife befinden. Zum Beispiel:

while (x==process(y));
if (z=x) {
    // do stuff.
}

Es wäre sehr leicht, obiges falsch zu interpretieren, da sich die if-Anweisung in der Schleife befindet, und selbst wenn Sie es richtig gelesen hätten, wäre es leicht zu glauben, dass es sich um einen Programmierfehler handelte und das if innerhalb der Schleife stehen sollte.

Mit do {} while(X); obwohl es sofort auf einen Blick klar ist, dass die Schleife keinen Körper hat.

Wenn Sie den Kommentar über dem Code lesen, wird erwähnt, dass …

Wenn der Anrufer nicht a ForkJoinTaskist diese Methode verhaltensmäßig äquivalent zu

while (!blocker.isReleasable())
   if (blocker.block())
      return;
}

Es ist also nur eine andere Form, den obigen Code im Else-Teil zu implementieren … !!

Im Style-Notizen es wird erwähnt,

Es gibt mehrere Vorkommen des ungewöhnlichen “do {} while (!cas…)”, das die einfachste Möglichkeit ist, eine Aktualisierung einer CAS-Variablen zu erzwingen.

Und wenn Sie die Umsetzung sehen werden ManagedLocker#isReleasableEs aktualisiert die Sperre und kehrt zurück true wenn eine Blockierung unnötig ist.

Deutung :

Leere While-Schleifen werden verwendet, um einen Interrupt bereitzustellen, bis eine Bedingung auf wahr/falsch zurückgesetzt wird.

Hier, do { } while(!...) ist ein Blocker/Interrupt bis blocker.block() wird sein true Wenn blocker.isReleasable() ist false. Die Schleife setzt die Ausführung fort, solange blocker ist nicht lösbar (!blocker.isReleasable()) und blocker ist nicht gesperrt !! Die Ausführung wird außerhalb der Schleife sein, sobald blocker.block() wird auf wahr gesetzt.

Beachten Sie, dass, do{ } while(...) aktualisiert die CAS-Variable nicht, aber es garantiert, dass das Programm wartet, bis die Variable aktualisiert wird (erzwingt das Warten, bis die Variable aktualisiert wird).

Du kannst so etwas ganz einfach machen mit:

if(true){
 //Do nothing ...
}