Funktion, die garantiert niemals denselben Wert zweimal zurückgibt [closed]

Dies ist eine Frage, die mir bei einem Vorstellungsgespräch gestellt wurde, und ich kann die gesuchte Antwort nicht herausfinden, also hoffe ich, dass jemand hier einige Ideen hat. Ziel ist es, eine Funktion zu schreiben, die garantiert niemals den gleichen Wert zweimal zurückgibt. Angenommen, auf diese Funktion können mehrere Computer gleichzeitig zugreifen.

Meine Idee war, jeder Maschine eine eindeutige ID zuzuweisen und diesen Wert an die Funktion zur Generierung eindeutiger Werte zu übergeben:

var i = 0;
function uniq(process_id, machine_id) {
   return (i += 1).toString() + machine_id + "-" + process_id;
}

Dies würde die Auswirkung von Race-Bedingungen vermeiden, da selbst dann, wenn zwei oder mehr Prozesse denselben Wert lesen i, jeder Rückgabewert mit einer eindeutigen Kombination aus Prozess-ID und Rechner-ID versehen wird. Meinem Interviewer gefiel diese Antwort jedoch nicht, da für das Online-Schalten einer anderen Maschine eine ID zugewiesen werden muss.

Kann sich jemand eine andere Lösung vorstellen, bei der nicht jeder Computer mit einer eindeutigen ID konfiguriert wird? Ich hätte gerne eine Antwort, falls diese Frage erneut auftaucht. Vielen Dank.

Machen Sie sich nichts vor, werfen Sie einfach einen einfachen (thread-sicheren) Zähler hinter einen Kommunikationsendpunkt (WCF, Webservice, was auch immer):

   long x = long.MinValue;
   public long ID(){
       return Interlocked.Increment(ref x);
   }

Ja, es wird irgendwann überlaufen. Ja, Neustarts werden nicht verarbeitet. Ja, es ist nicht zufällig. Ja, jemand könnte dies auf mehreren Servern ausführen.

Dies ist das Einfachste, was die praktischen Anforderungen erfüllt. Lassen Sie sie diejenigen sein, die sich mit diesen Problemen befassen (um sicherzustellen, dass sie die Einschränkungen verstehen, glauben sie wirklich, dass Sie mehr als 2 ^ 64 IDs benötigen), damit Sie sich fragen können, welche Kompromisse in Ordnung sind. Muss es Neustarts überleben? Was ist mit Festplattenausfall? Was ist mit Atomkrieg? Muss es zufällig sein? Wie zufällig?

Wenn mir diese Frage gestellt würde und sie klar machen würde, dass sie für Neustarts und für verschiedene Computer eindeutig sein muss, würde ich ihnen eine Funktion geben, die den Standardmechanismus zum Erstellen einer neuen GUID aufruft, unabhängig davon, in welchem ​​Bereich sich diese befindet die verwendete Sprache.

Der Interviewer sagte, die Methode werde gleichzeitig aufgerufen, nicht parallel; Stellen Sie das Datum und die Uhrzeit auf so viele Dezimalstellen wie möglich zurück.

Warum überdenken das alle? Sie werden lange Zeit tot sein, bevor die Endlichkeit aufgebraucht ist und Sie keine Chance auf eine Kollision haben.

Wenn Sie befürchten, dass es zur gleichen Zeit zurückkehrt, fügen Sie eine Verzögerung für die kleinste meßbare Zeit hinzu.

Wenn Sie Bedenken haben, die Uhr für die Sommerzeit zurückzusetzen (zweimal 1 Mal), fügen Sie der Zeit beim zweiten Mal eine Konstante hinzu.

Zunächst möchten Sie dem Interviewer zwei Fragen stellen.

Frage 1.

ob der Interviewer erwartet, dass eine oder mehrere "zentrale Maschinen" verwendet werden, um einige eindeutige Nummern oder Blöcke von eindeutigen Nummern zuzuweisen.

Frage 2.

Ob der Interviewer einen Mechanismus zur Kollisionserkennung erwartet oder stattdessen das berechnete Risiko einer winzigen Kollisionswahrscheinlichkeit akzeptiert, ohne diese explizit zu erkennen.

Es gibt auch den Ansatz der Tiefenverteidigung, bei dem ein Teil der Benutzer-ID in die Zufälligkeit einbezogen wird (also nicht ganz zufällig ist). Die Wahrscheinlichkeit, dass derselbe Benutzer auf eine Kollision innerhalb des von demselben Benutzer erstellten Inhalts stößt, wird daher verringert.

Es gibt eine implizite Frage 3, ...

Aber es ist eine, die Sie selbst beurteilen müssen, ohne zu fragen, denn es ist äußerst unhöflich, Ihren Interviewer zu fragen.

Ob der Interviewer das Wissen über Wahrscheinlichkeit, Risiko und einige einfache Techniken, die in kryptografischen Systemen und Informationssicherheitssystemen verwendet werden, voraussetzt.

Die erste Art von Wissen stellt sicher, dass Sie nicht versuchen, eine nicht wissenschaftliche Person davon zu überzeugen, ein wissenschaftliches Konzept zu akzeptieren, das sie nicht akzeptiert.

Die zweite Art von Wissen stellt sicher, dass Sie Bedenken ansprechen, die zusätzlich zur bloßen Wahrscheinlichkeit auftreten. Mit anderen Worten, wie Sie sich gegen "Angreifer" verteidigen können, die Ihr Zufallsschema absichtlich aufheben möchten, indem Sie die Maschine (n) oder ihre virtuellen Hosts so manipulieren, dass zwei Maschinen denselben Wert generieren.

Warum fragst du.

Der Grund ist, dass, wenn der Interviewer es auf die eine oder andere Weise erwartet, der Versuch, mit dem entgegengesetzten Ansatz zu antworten, den Interviewer niemals glücklich macht.

Der tiefere Grund ist, dass einige Leute die Idee nicht mögen, eine 1.0e-20Chance des Scheiterns zu sagen . (Ich werde versuchen, hier keine philosophischen oder religiösen Argumente hervorzurufen.)

Zunächst wird der "Namensraum" von Zufallszahlen zu einer Hierarchie zusammengesetzt, wobei einer Zufallsquelle eine bestimmte Anzahl von Bits und auf andere Weise die andere Anzahl von Bits usw. zugewiesen wird.

Der zentralisierte Ansatz beruht auf einer zentralen Autorität, um die erste Ebene von Bits eindeutig zuzuweisen. Dann können die anderen Maschinen den Rest der Bits füllen.

Es gibt mehrere dezentrale Ansätze:

• Erzeugen Sie einfach Zufallszahlen, so gut es geht, und akzeptieren Sie die praktisch Null-Chance, rechnerisch gerechtfertigt zu versagen.
• Verwenden Sie kryptografische Mittel, um Zufallswerte aus deterministischen Quellen zu generieren, z. B. inkrementierende Werte.

In Anbetracht dessen, dass dies eine Interviewfrage und kein reales Szenario ist, glaube ich, dass der richtige Ansatz (und wahrscheinlich das, wonach der Interviewer sucht) darin besteht, eine klärende Frage zu stellen oder zu schreiben, dass dies nicht möglich ist fertig sein "und weitermachen. Hier ist der Grund.

Was der Interviewer fragt:

Schreiben Sie eine Funktion, die garantiert niemals denselben Wert zweimal zurückgibt. Angenommen, auf diese Funktion können mehrere Computer gleichzeitig zugreifen.

Was der Interviewer braucht:

Bewertet dieser Kandidat die Anforderungen effektiv und sucht er bei Bedarf zusätzlichen Input?

Niemals annehmen.

Wenn ein Ingenieur eine Anforderung erhält (über eine Leistungsbeschreibung oder eine Spezifikation oder ein anderes Anforderungsdokument), sind einige offensichtlich und andere völlig unklar. Dies ist ein perfektes Beispiel für Letzteres. Wie die vorherigen Antworten gezeigt haben, gibt es keine Möglichkeit, auf diese Anforderung zu reagieren, ohne mehrere wichtige Annahmen zu treffen, entweder (a) hinsichtlich der Art der Frage oder (b) hinsichtlich der Art des Systems, da die Anforderung nicht erfüllt werden kann wie geschrieben (es ist unmöglich).

Die meisten Antworten versuchen auf die eine oder andere Weise, das Problem über eine Reihe von Annahmen zu lösen. Es wird ausdrücklich empfohlen, dies nur schnell zu erledigen und dem Kunden zu überlassen, ob es falsch ist.

Das ist wirklich ein schlechter Ansatz. Wenn ich als Kunde eine unklare Anforderung stelle und der Ingenieur losgeht und mir eine Lösung baut, die nicht funktioniert, bin ich verärgert, dass sie zur Arbeit gegangen sind und mein Geld ausgegeben haben, ohne sich die Mühe gemacht zu haben, mich zuerst zu fragen. Diese Art der unbekümmerten Entscheidungsfindung zeigt einen Mangel an Teamwork, Unfähigkeit, kritisch zu denken und schlechtes Urteilsvermögen. Dies kann zu jeglichen negativen Konsequenzen führen, einschließlich dem Verlust von Leben in einem sicherheitskritischen System.

Warum die Frage stellen?

Der springende Punkt bei dieser Übung ist, dass es teuer und zeitaufwendig ist, mehrdeutige Anforderungen zu erfüllen. Im Fall des OP wurde Ihnen eine unmögliche Aufgabe übertragen. Ihre erste Maßnahme sollte darin bestehen, um Klärung zu bitten - was ist erforderlich? Welcher Grad an Einzigartigkeit ist erforderlich? Was passiert, wenn ein Wert nicht eindeutig ist? Die Antwort auf diese Fragen kann der Unterschied zwischen mehreren Wochen und einigen Minuten sein. In der realen Welt sind unklare und schlecht verstandene Anforderungen einer der größten Kostentreiber in komplexen Systemen (einschließlich vieler Softwaresysteme). Dies führt zu teuren und zeitraubenden Fehlern, Neukonstruktionen, Frustrationen von Kunden und Teams und zu einer peinlichen Berichterstattung in den Medien, wenn das Projekt groß genug ist.

Was passiert, wenn Sie annehmen?

Angesichts meines Hintergrunds in der Luft- und Raumfahrtindustrie und aufgrund der weithin sichtbaren Fehler in der Luft- und Raumfahrt möchte ich Beispiele aus diesem Bereich anführen, um wichtige Punkte zu veranschaulichen. Lassen Sie uns ein Paar fehlgeschlagener Mars-Missionen untersuchen - den Mars Climate Orbiter und den Mars Polar Lander. Beide Missionen scheiterten an Softwareproblemen - weil die Ingenieure teilweise aufgrund unklarer und schlecht kommunizierter Anforderungen ungültige Annahmen machten.

Mars Climate Orbiter - In diesem Fall wird normalerweise angegeben, was passiert, wenn die NASA versucht, Englisch in metrische Einheiten umzurechnen. Dies ist jedoch eine übermäßig vereinfachte und schlechte Darstellung dessen, was wirklich passiert ist. Es stimmte, es gab ein Konvertierungsproblem, das jedoch auf schlecht kommunizierte Anforderungen in der Entwurfsphase und ein falsches Überprüfungs- / Validierungsschema zurückzuführen war. Wenn zwei verschiedene Ingenieure das Problem bemerkten, weil es anhand der Flugbahndaten offensichtlich war, brachten sie das Problem nicht auf das richtige Niveau, da sie davon ausgegangen waren, dass es sich um einen Übertragungsfehler handelte. Wäre das Einsatzteam auf das Problem aufmerksam gemacht worden, hätte es genügend Zeit, es zu beheben und die Mission zu retten. In diesem Fall gab es eine unmögliche logische Bedingung, die nicht als solche erkannt wurde und zu einem kostspieligen Misserfolg führte.

Mars Polar Lander- Dieser Fall ist etwas weniger bekannt, aber möglicherweise aufgrund seiner zeitlichen Nähe zum Mars Climate Orbiter-Fehler peinlicher. In dieser Mission steuerte die Software den strahlruderunterstützten Abstieg der Rakete in die Marsoberfläche. An einem Punkt 40 Meter über der Oberfläche wurden die Beine des Landers zur Vorbereitung der Landung eingesetzt. An den Beinen befand sich außerdem ein Sensor, der Bewegungen feststellte (um zu signalisieren, wann sie aufprallten), um die Software anzuweisen, den Motor abzustellen. Die NASA schätzt am besten, was passiert ist (da es mehrere mögliche Ausfälle und unvollständige Daten gibt), dass zufällige Vibrationen in den Beinen aufgrund ihres Einsatzes gleichzeitig und unkorrekterweise den Abschaltmechanismus 40 m über der Oberfläche ausgelöst haben, was zum Absturz und zur Zerstörung des $ 110 führte M Raumschiff. Diese Möglichkeit wurde in der Entwicklung aufgeworfen, wurde aber nie angesprochen. Letztendlich machte das Software-Team ungültige Annahmen darüber, wie dieser Code ausgeführt werden musste (eine solche Annahme ist, dass ein Störsignal zu kurzlebig ist, um trotz gegenteiliger Tests aufgenommen zu werden), und diese Annahmen wurden erst danach in Frage gestellt die Tatsache.

Weitere Überlegungen

Menschen zu interviewen und zu bewerten ist eine knifflige Angelegenheit. Es gibt verschiedene Dimensionen eines Kandidaten, die ein Interviewer untersuchen möchte, aber eine der wichtigsten ist die Fähigkeit eines Einzelnen, kritisch zu denken. Aus einer Vielzahl von Gründen, nicht zuletzt weil das kritische Denken schlecht definiert ist, haben wir es sehr schwer, die Fähigkeit zum kritischen Denken zu bewerten.

Als Ingenieurlehrer war es eine meiner Lieblingsmethoden, die Fähigkeit eines Schülers, kritisch zu denken, zu bewerten, eine etwas mehrdeutige Frage zu stellen. Die schärferen Schüler würden die fehlerhafte Prämisse der Frage aufgreifen, sie notieren und sie entweder unter der Voraussetzung beantworten oder ablehnen, um sie insgesamt zu beantworten. Normalerweise würde ich eine Frage stellen, die der folgenden ähnelt:

Sie nehmen eine Zeichnung von Ihrem Stapel Arbeit auf. Die Zeichnung enthält eine Vielzahl verschiedener Beschriftungen, die wichtigsten jedoch weisen auf eine horizontale Fläche und sagen "Perfekt flach". Die Oberfläche ist 5 "breit und 16" lang, und das Teil besteht aus Aluminium. Wie werden Sie das Teil bearbeiten, um diese Funktion zu erstellen?

(Übrigens, Sie wären schockiert darüber, wie oft eine so schlechte Spezifikation am Arbeitsplatz auftritt.)

Ich erwarte, dass die Schüler erkennen, dass es nicht möglich ist, ein perfektes Feature zu erstellen, und dass sie dies in ihrer Antwort angeben. Normalerweise würde ich einen Bonuspunkt vergeben, wenn sie sagen, dass sie zum Designer zurückkehren und ihn um Klärung bitten, bevor sie das Teil herstellen. Wenn ein Schüler mir mitteilt, wie er die .001-Planarität oder einen anderen erfundenen Wert erreicht, gebe ich null Punkte. Dies hilft mir, meinen Schülern klar zu machen, dass sie über das Gesamtbild nachdenken müssen.

Endeffekt

Wenn ich einen Ingenieur (oder einen ähnlichen Beruf) interviewe, suche ich jemanden, der kritisch denken und hinterfragen kann, was ihm vorgelegt wurde. Ich möchte jemanden, der die Frage stellt: "Ergibt das einen Sinn?" .

Es macht keinen Sinn, nach einem vollkommen flachen Teil zu fragen, denn es gibt kein vollkommenes Teil. Es ist nicht sinnvoll, nach einer Funktion zu fragen, die niemals einen doppelten Wert zurückgibt, da es unmöglich ist, eine solche Garantie zu geben. In der Programmierung hören wir oft den Satz "Müll rein, Müll raus". Wenn Ihnen Müll für Anforderungen ausgehändigt wird, liegt es in Ihrer ethischen Verantwortung, anzuhalten und Fragen zu stellen, die Ihnen dabei helfen, die wahre Absicht herauszufinden. Wenn ich einen Kandidaten interviewe und ihm eine unklare Anforderung vorlege, erwarte ich Klärungsfragen.

Die Gewährleistung der Eindeutigkeit ist schwierig, da Computer nicht über unendlich große Variablen verfügen. Keine echte Turingmaschine kann das.

Meiner Meinung nach gibt es hier zwei Probleme, und beide haben gut etablierte Lösungen.

• Parallelität. Möglicherweise benötigen mehrere Computer gleichzeitig einen Wert. Zum Glück sind in modernen CPUs Nebenläufigkeiten integriert, und einige Sprachen bieten entwicklerfreundliche Funktionen, um diese zu nutzen.
• Einzigartigkeit. Obwohl es unmöglich ist, die Eindeutigkeit zu garantieren, können wir willkürlich große Variablen haben, die Werte enthalten können, die so groß sind, dass es für ein reales System sehr schwierig wäre, alle eindeutigen Werte zu erschöpfen

Hier ist meine Lösung in Java:

public class Foo {
  private static BigInteger value = BigInteger.ZERO;
  private static final Lock lock = new ReentrantLock();

  public static BigInteger nextValue() {
    try {
      lock.lock();
      value = value.add(BigInteger.ONE);
      return value;
    }
    finally {
      lock.unlock();
    }
  }
}

BigInteger ist ein Integer-Typ beliebiger Größe. Es kann wachsen, um Werte zu halten, die ziemlich groß sind, auch wenn sie nicht unendlich sind. Die Sperre stellt die Parallelität sicher, sodass der gleiche Wert nicht zweimal von zwei gleichzeitigen Anforderungen zurückgegeben werden kann, die von separaten Threads bearbeitet werden.

Ich würde die Funktion über einen Port auf dem Server aussetzen; Um die Funktion aufzurufen, fordert die anfordernde Maschine eine Verbindung an und erhält eine, während gleichzeitig ein Identifizierungscode zugewiesen wird (der Einfachheit halber fortlaufende Nummer). Immer wenn eine Nachricht an den Port gesendet wird, die den eindeutigen Wert anfordert, wird der Wert generiert, indem der MD5-Hash des aktuellen Datums und der Uhrzeit mit dem MD5-Hash des Identifizierungscodes verkettet wird.

Wenn sie eine kugelsichere Lösung wünschen, müssten sie ihre tatsächlichen Anforderungen spezifizieren, anstatt alles vage zu sagen.

string uniq(string machine_id) 
{
   static long u = long.MinValue;
   Interlocked.Increment(ref u);

   //Time stamp with millisecond precison
   string timestamp = DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss.fff",
                                            CultureInfo.InvariantCulture);

   return machine_id + "-" + timestamp + "-" + u;
}

Auf die obige Weise können wir sicherstellen, dass der Rückgabewert unterschiedlich ist, auch wenn ein Neustart vorliegt oder wenn er von verschiedenen Computern gleichzeitig aufgerufen wird.