[C] thread safety



  • Blue-Tiger schrieb:

    warum reden hier eigentlich alle ueber Locks etc? Alles was der Benutzer brauch ist eine getThreadNumber() und ein Array statt einer globalen Variable. Dann kann er sich jegliche Synchronisation auch komplett ersparen 😕

    getThreadNumber(), ja, klar. Blödsinn. Thread-ID wenn schon. Und Thread-IDs haben so die Angewohnheit total beliebige Nummern, meist min. 32 Bit breit, zu sein. Also wird ihm ein Array nicht viel bringen.



  • hustbaer schrieb:

    Blue-Tiger schrieb:

    warum reden hier eigentlich alle ueber Locks etc? Alles was der Benutzer brauch ist eine getThreadNumber() und ein Array statt einer globalen Variable. Dann kann er sich jegliche Synchronisation auch komplett ersparen 😕

    getThreadNumber(), ja, klar. Blödsinn. Thread-ID wenn schon. Und Thread-IDs haben so die Angewohnheit total beliebige Nummern, meist min. 32 Bit breit, zu sein. Also wird ihm ein Array nicht viel bringen.

    Nein, ich meinte getThreadNumber(), nicht getThreadID. Es gibt sehr wohl Thread-Libs, welche die IDs "durchnummerieren", OpenMP zum Beispiel. Und wenn der OP nicht eine solche einsetzt, muss eben eine (synchronisierte) ID->Nummer Map her, das versteht sich wohl von selbst.

    EDIT: oder eine (insofern die Implementierung threadsafe ist nichtmal notwendigerweise synchronisierte) ID -> Filedescriptor Map. Vermutlich sind die meisten Maps aber nicht Threadsafe, also waere das wohl eine langsamere Sache.

    Eine andere Idee waer, die globalen Descriptoren einfach Thread-global zu machen (widerum: OpenMP kann das, k.A. wie's mit anderen APIs ausschaut).



  • tfa schrieb:

    Selten so viel Unsinn gelesen.

    *fricky ist ein Troll, einfach ignorieren. Er ändert übrigens seinen Nick hin und wieder, aber man erkennt ihn sofort.



  • MFK schrieb:

    Er ändert übrigens seinen Nick hin und wieder, aber man erkennt ihn sofort.

    ja, ab gestern trage ich das sternchen vorn. ~ war mir auf dauer zu langweilig.
    🙂



  • Blue-Tiger schrieb:

    hustbaer schrieb:

    Blue-Tiger schrieb:

    warum reden hier eigentlich alle ueber Locks etc? Alles was der Benutzer brauch ist eine getThreadNumber() und ein Array statt einer globalen Variable. Dann kann er sich jegliche Synchronisation auch komplett ersparen 😕

    getThreadNumber(), ja, klar. Blödsinn. Thread-ID wenn schon. Und Thread-IDs haben so die Angewohnheit total beliebige Nummern, meist min. 32 Bit breit, zu sein. Also wird ihm ein Array nicht viel bringen.

    Nein, ich meinte getThreadNumber(), nicht getThreadID. Es gibt sehr wohl Thread-Libs, welche die IDs "durchnummerieren", OpenMP zum Beispiel. Und wenn der OP nicht eine solche einsetzt, muss eben eine (synchronisierte) ID->Nummer Map her, das versteht sich wohl von selbst.

    EDIT: oder eine (insofern die Implementierung threadsafe ist nichtmal notwendigerweise synchronisierte) ID -> Filedescriptor Map. Vermutlich sind die meisten Maps aber nicht Threadsafe, also waere das wohl eine langsamere Sache.

    Eine andere Idee waer, die globalen Descriptoren einfach Thread-global zu machen (widerum: OpenMP kann das, k.A. wie's mit anderen APIs ausschaut).

    OK.
    Libs welche Thread-Nummern vergeben anstelle von IDs sind aber die Ausnahme und nicht die Regel. Weiters muss eine obere Schranke bekannt sein wenn man ein unsynchronisiertes Array verwenden möchte.
    IMO halt keine sehr hilfreiche Antwort wenn man schreibt "is doch alles ganz einfach, machst du XYZ und gut" (sinngemäss), XYZ aber leider nur in ganz wenigen Spezialfällen möglich/anwendbar ist.

    Was synchronisierte Maps angeht: is dann aber auch nimmer "ganz einfach". Kann man gleich diverse TLS-Funktionen (WinAPI, pthreads, ...) verwenden. Bei pthreads bekommt man z.B. netterweise auch "deleter" mitgeliefert. Gerade wenn man File-Handles offen hat kann das denke ich sehr nützlich sein.


Anmelden zum Antworten