3. Cross-thread calls

Cross-thread calls

  • S

    Wenn du denkst dass Information fehlt, dann ergaenze sie einfach.
    Ein Forenpost ist kein Fachartikel - es wird immer Verbesserungen geben und man recherchiert keine 3 Tage fuer den Inhalt. Man schreibt einfach was einem einfaellt und versucht zu helfen.

    Wenn du denkst, dass die Information zu Critical Sections wichtig ist, dann schreib sie einfach hin, no biggy 🙂

    0
  • T

    hustbaer schrieb:

    Nur ein Hinweis: Critical Sections unter Windows *sind* Mutexen. Bloss ein anderer Name, und man kann sie halt nicht prozessübergreifend verwenden.
    Das was Windows "Mutex" nennt ist ein Kernel-Objekt, und als solches ziemlich langsam.

    Ich weiß, deshalb habe ich ja auch geschrieben:

    theliquidwave schrieb:

    (bzw. den Vorteil von Critical Sections unter Windows)

    Trotzdem danke für den Hinweis 😉

    hustbaer schrieb:

    Tu das, drüberschauen kann ich auf jeden Fall mal.

    Danke, mache ich morgen...

    hustbaer schrieb:

    Naja, Windows hat statt Condition-Variablen sog. "Events" angeboten. Mit denen kann man auch ganz gut arbeiten, allerdings nicht ganz so unkompliziert und problemlos wie mit Condition-Variablen.

    Okay.

    hustbaer schrieb:

    Weil die ausser langsam nur langsam sind?

    In der MSDN steht nur, dass Critical Sections "sligthy faster" sind als Mutexes...

    0

  • theliquidwave schrieb:

    hustbaer schrieb:

    Weil die ausser langsam nur langsam sind?

    In der MSDN steht nur, dass Critical Sections "sligthy faster" sind als Mutexes...

    Uff. Ich müsste den Unterschied mal ausmessen. Würde mich aber wundern wenn es nur "sligthy" wäre.

    Critical-Sections sind Usermode spin-sleep Locks, also das schnellste was man so an nicht spezialisierten Mutexen bauen kann.

    Ne Win32 Mutex ist dagegen wie gesagt ein Kernel-Objekt. D.h. es müssen mehrere Dinge passieren wenn man damit was machen will

    1. Kernelmode-Transition
    2. Handle-Lookup & Ermittlung des Handle-Typs
    3. Security-Check, inklusive Check ob der aufrufende Prozess überhaupt berechtigt ist mit dem übergebenen HANDLE zu arbeiten
    4. Die eigentliche Aktion
    5. Transition zurück in den Usermode
    0

  • So. Hab mal nen ganz einfachen Test gemacht - bloss ein Thread, d.h. keine Lock-Contention, einfach nur mal gucken wie schnell man CS vs. Win32-Mutex erzeugen + zerstören kann, dann erzeugen + zerstören mit 1x lock+unlock dazwischen, und dann erzeugen, 10000x lock/unlock dazwischen und dann zerstören:

    Mit MSVC 2012 std::chrono::high_resolution_clock (aka. GetSystemTimeAsFileTime()):

    class CriticalSectionNoDebugInfo create/destroy = 2929 us (base)
class CriticalSectionNoDebugInfo create/lock/unlock/destroy = 8789 us (base)
class CriticalSectionNoDebugInfo lock/unlock = 47851 us (base)

class CriticalSection create/destroy = 31250 us = 10.6666 * base
class CriticalSection create/lock/unlock/destroy = 35156 us = 3.99998 * base
class CriticalSection lock/unlock = 46875 us = 0.979593 * base

class Win32Mutex create/destroy = 193359 us = 65.9997 * base
class Win32Mutex create/lock/unlock/destroy = 308593 us = 35.111 * base
class Win32Mutex lock/unlock = 1149414 us = 24.0204 * base

    Mit my_highres_clock aka. QueryPerformanceCounter():

    class CriticalSectionNoDebugInfo create/destroy = 3691 us (base)
class CriticalSectionNoDebugInfo create/lock/unlock/destroy = 8498 us (base)
class CriticalSectionNoDebugInfo lock/unlock = 46898 us (base)

class CriticalSection create/destroy = 30244 us = 8.19254 * base
class CriticalSection create/lock/unlock/destroy = 34650 us = 4.07736 * base
class CriticalSection lock/unlock = 46955 us = 1.00123 * base

class Win32Mutex create/destroy = 192070 us = 52.0267 * base
class Win32Mutex create/lock/unlock/destroy = 307289 us = 36.1587 * base
class Win32Mutex lock/unlock = 1144865 us = 24.4117 * base

    "sligthy faster" kommt also nicht so ganz hin. > Faktor 20 ist bei mir nicht mehr "sligthy" 🙂

    0

  • hustbaer schrieb:

    1. Security-Check, inklusive Check ob der aufrufende Prozess überhaupt berechtigt ist mit dem übergebenen HANDLE zu arbeiten

    OK, "Security-Check" ist Quatsch, der ist nur nötig wenn man versucht ein neues HANDLE zu bekommen, und das tut man bei WaitForSingleObject/ReleaseMutex ja nicht.
    Der Check ob der aktuelle Prozess mit diesem HANDLE arbeiten darf ist hier denke ich schon nötig. HANDLE-Werte sind IIRC ja prozessübergreifend, aber nicht jeder Prozess darf mit jedem HANDLE arbeiten.

    0
  • T

    Krass o_O Danke für's testen 👍
    Ich werde den Code noch ein bisschen verfeinern und nachher hochladen.
    Aber sei gewarnt, ich code seit 3 Tagen mit Notepad++ ohne jede Chance auf einen Compiler. Ich bin schon gespannt, wenn ich das Projekt zum ersten mal durch einen Compiler schiebe 😃

    0
Anmelden zum Antworten