Was bedeutet “inhärent Thread-sicher”?

Lesezeit: 7 Minuten

Benutzeravatar von Vikram
Vikram

Ich bin auf diese Zeile gestoßen “Einige Funktionen sind zum Beispiel von Natur aus Thread-sicher memcpy()

Wikipedia definiert “threadsicher” als:

Ein Codestück ist Thread-sicher, wenn es nur gemeinsam genutzte Datenstrukturen so manipuliert, dass eine sichere Ausführung durch mehrere Threads gleichzeitig gewährleistet ist.

OK. Aber was tut von Natur aus bedeuten? Liegt es an der Erbschaft?

  • @Thilo Ich habe es hier gelesen – infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0349c/…

    – Wikram

    7. April 2014 um 9:41 Uhr

  • Sieht so aus, als hätten Sie eine englische Verwirrung, keine Programmierverwirrung. Die Wörter “inhärent” und “erben” sind nicht verwandt: dictionary.reference.com/browse/inherent

    – Benutzer2357112

    7. April 2014 um 9:51 Uhr

  • Komisch ist, dass der zitierte Satz über alle Maßen absurd ist. Während memcpy muss natürlich den freigegebenen Zustand nicht berühren (und ist es daher naiv Thread-sicher), ändert es beliebige Speicherbereiche auf unsynchronisierte Weise, was ganz offensichtlich überhaupt nicht Thread-sicher ist.

    – Dämon

    7. April 2014 um 16:36 Uhr

  • Nun, sollte die Tag-Vererbung dann von der Frage entfernt werden?

    – Benutzer1306322

    7. April 2014 um 18:13 Uhr

  • @Damon: Das sogenannte “absurde” Zitat verwendet die Definition von “thread-safe” aus dem Posix-Standard. memcpy wird von Posix benötigt, um unter dieser Definition Thread-sicher zu sein. Das Zitat aus Wikipedia stimmt nicht unbedingt mit dieser Definition überein, obwohl es so wäre, wenn wir es wären sehr Achten Sie darauf, was wir unter “gemeinsamen Datenstrukturen” verstehen. Für Sie ist es also nur absurd, weil Sie den Kontext verpassen, in dem “thread-safe” definiert ist. Die Tags sind unglücklich, da sich die übliche Bedeutung von “thread-safe” in Java von der üblichen Bedeutung in C unterscheidet.

    – Steve Jessop

    7. April 2014 um 22:20 Uhr


Benutzeravatar von peter.petrov
peter.petrow

Es hat nichts mit Erbschaft zu tun. Es ist ein informeller Ausdruck und bedeutet eher wie
“Einige Funktionen sind von Natur aus Thread-sicher”. Zum Beispiel eine Funktion, die dies nicht tut
Berühren Sie alle freigegebenen Werte / Zustände, ist sowieso Thread-sicher, dh “ist von Natur aus Thread-sicher”.

  • +1 für “von Natur aus” (im Gegensatz zu besonderen Vorkehrungen, um sie threadsicher zu machen).

    – Thilo

    7. April 2014 um 9:34 Uhr

  • Es hat tatsächlich nichts mit Erbschaft zu tun. Die Wörterbuchdefinition lautet sogar „inhärent – ​​als wesentlicher Bestandteil oder Eigenschaft vorhanden; intrinsisch“.

    – Nr

    7. April 2014 um 9:34 Uhr

  • Interessant. Ich dachte immer, dass “inhärent” und “ererbt” verwandt sind. Wie „inhärent“ = „Eigenschaft, die aufgrund der Abstammung/Vererbung/Zugehörigkeit zu einer Gruppe zweifellos vorhanden ist“. Aber es sieht so aus, als hätten sie tatsächlich unterschiedliche Wurzeln (“heredito” vs. “haereo”).

    – Ark-kun

    7. April 2014 um 18:27 Uhr

  • +1 für den Hinweis, dass es sich um einen informellen Ausdruck ohne technische, präzise Bedeutung handelt.

    – Kevin

    8. April 2014 um 1:35 Uhr

Benutzeravatar von unwind
entspannen

In diesem Zusammenhang interpretiere ich es als “ohne dafür entwickelt worden zu sein, ist es immer noch Thread-sicher”.

Es gibt keine direkte Verbindung zum Konzept der Vererbung, obwohl die Wörter natürlich verwandt sind. Dies ist natürlich kein Beispiel für Vererbung im Sinne der objektorientierten Programmierung. Dies ist nur eine Funktion, die von ihrer Kernnatur die Eigenschaft erhält, Thread-sicher zu sein.

Natürlich gibt es nichts Zauberhaftes memcpy() entweder inhärent Thread-sicher sein. Jede Funktion ohne internen Status oder “gemeinsame” Nebeneffekte wird dies auch sein, weshalb Funktionale Programmierungwo alle Funktionen “rein” sein sollen und keine Nebenwirkungen haben, eignet sich so gut für die parallele Programmierung.

In der Praxis ist es auf typischen Computern schwierig, “echte Arbeit” ohne Nebeneffekte zu erledigen, insbesondere I/O wird sehr stark durch seine Nebeneffekte definiert. So haben auch rein funktionale Sprachen oft einige nicht-funktionale Ecken.

Aktualisieren: Na sicher, memcpy() ist nicht frei von Nebeneffekten, sein Hauptzweck ist es, Speicher zu manipulieren, der, wenn er von Threads gemeinsam genutzt wird, sicherlich nicht sicher ist. Es muss davon ausgegangen werden, dass es, solange die Zielbereiche verschieden sind, keine Rolle spielt, ob ein oder mehrere Threads laufen memcpy() parallel zu.

Vergleichen Sie dies mit zB printf(), die Zeichen in einem einzigen (für den Prozess) Ausgabestrom generiert. Es muss explizit implementiert werden (wie von POSIX gefordert), um Thread-sicher zu sein, wohingegen memcpy() nicht.

  • Wie hängen die Wörter zusammen? Ich sehe ein indogermanisches ghē, das in einem Wörterbuch für “Erbschaft” erwähnt wird, aber ich weiß nicht, ob es dieselbe Wurzel wie “inhärent” ist oder nicht …

    – Steve Jessop

    7. April 2014 um 15:13 Uhr


  • @SteveJessop Sie sind semantisch überhaupt nicht verwandt. Siehe die Fragenkommentare und die Antwort von peter.petrov. Sie kann etwas Etymologie teilen, aber ich würde auch nicht darauf wetten.

    Benutzer395760

    7. April 2014 um 15:31 Uhr


  • @delnan: richtig, ich habe diese Aussagen gesehen. Diese Antwort stimmt zu, dass die Programmierkonzepte nicht verwandt sind. Aber wenn wir uns entspannen, wird er mir etwas TORTE auflegen und seine separate Behauptung beweisen, dass die Wörter semantisch verwandt sind, weil “to inhere” dieselbe Wurzel wie lateinisch “hereditas” hat, dann würde ich das genießen, also hoffe ich, dass er es tut 🙂 Man könnte immer noch bestreiten, dass eine solche Beziehung “offensichtlich” ist, aber wenn es nur darauf ankommt, welches Allgemeinwissen man hat, dann ist das für die, die es wissen, offensichtlich und nicht für die, die es nicht wissen.

    – Steve Jessop

    7. April 2014 um 15:41 Uhr


Benutzeravatar von Vality
Wertigkeit

Eine inhärent Thread-sichere Funktion ist sicher, ohne dass bestimmte Konstruktionsentscheidungen bezüglich des Threadings getroffen werden müssen, sie ist Thread-sicher einfach aufgrund der Aufgabe, die sie ausführt, im Gegensatz zu einer Umgestaltung, um Thread-Sicherheit zu erzwingen. Angenommen, ich schreibe die sehr einfache Funktion:

int cube(int x)
{
    return x*x*x;
}

Es ist von Natur aus Thread-sicher, da es keine Möglichkeit hat, gemeinsam genutzten Speicher zu lesen oder in ihn zu schreiben. Ich könnte jedoch auch eine Funktion erstellen, die nicht Thread-sicher ist, aber durch spezifisches Design und Synchronisierung Thread-sicher machen. Angenommen, ich habe diese ähnliche Funktion wie zuvor:

void cubeshare()
{
    static int x;
    x = x * x * x;
    printf("%l", x);
}

Dies ist nicht Thread-sicher, es ist durchaus möglich, dass sich der Wert von x zwischen jeder Verwendung ändert (naja, das ist in Wirklichkeit unwahrscheinlich, da x zwischengespeichert würde, aber sagen wir, wir führen keine Optimierung durch).

Wir könnten diesen Thread jedoch so sicher machen (das ist Pseudocode, ein echter Mutex ist komplizierter):

void cubesharesafe(mutex foo)
{
    static int x;
    lockmutex(foo);
    x = x * x * x;
    printf("%l", x);
    unlockmutex(foo);
}

Dies ist jedoch nicht von Natur aus Thread-sicher, wir erzwingen dies durch Redesign. Reale Beispiele werden oft viel komplizierter sein, aber ich hoffe, dass dies eine möglichst einfache Idee vermittelt. Wenn Sie Fragen haben, kommentieren Sie bitte unten.

  • @SteveJessop Hallo, könnten Sie einen Blick darauf werfen, ob dieses Beispiel besser ist? Danke.

    – Wertigkeit

    7. April 2014 um 18:36 Uhr

  • @SteveJessop: Ein typisches memcpy Die Implementierung ist nicht blockierend und Thread-sicher, wenn sie nicht zum Schreiben von Speicher verwendet wird, der von einem anderen Thread verwendet werden kann, oder zum Lesen von Speicher, der von einem anderen Thread geschrieben werden kann. Eine Implementierung, die einen DMA-Controller verwenden würde, um Bewegungen größer als eine bestimmte Größe durchzuführen, könnte schneller sein als eine typische Implementierung, könnte aber ohne Betriebssystemunterstützung wahrscheinlich nicht sowohl nicht blockierend als auch threadsicher sein, selbst wenn auf alle Speicherbereiche von verschiedenen Threads zugegriffen würde völlig disjunkt.

    – Superkatze

    7. April 2014 um 19:12 Uhr

  • @Vality: Ja, für mich bedeutet das wahrscheinlich das ursprüngliche Zitat memcpy ist “inhärent” Thread-sicher.

    – Steve Jessop

    7. April 2014 um 22:19 Uhr

Benutzeravatar von Mik378
Mich378

Im Falle von memcpykann nur ein einzelner Thread Schreibvorgänge von einer bestimmten Quelle zu einem bestimmten Ziel bereitstellen. : Thread-sicher durch ursprüngliches Design so.

Von Natur aus bedeutet: ohne die Basisfunktion “tunen” zu müssen, um das Ziel zu erreichen, in diesem Fall: Thread-Sicherheit.

Wenn mehrere Threads denselben “Kanal” gleichzeitig stören könnten, würden Sie am Ende ein Problem mit der Thread-Sicherheit im Zusammenhang mit gemeinsam genutzten Daten-Chucks haben.

inhärente Mittel In etwas als Dauerhaftes existieren.
es hat nichts mit Vererbung zu tun … standardmäßig sind einige Methoden Thread-sicher … um zu schützen oder zu vermeiden Multitasking probleme..
Vektor, Hash-Tabelle… sind einige der Beispielklassen, die von Natur aus Thread-sicher sind … nichts … verwirrend … es gibt einige Funktionen … die standardmäßig Thread-sicher sind …

1388160cookie-checkWas bedeutet “inhärent Thread-sicher”?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy