Da jeg for nyligt investerede i en multiprocessorsbundkort, foretog
jeg et par tidstagninger ang. synkronisering mellem tr†de. Det gav et
par overaskelser! Disse observationer/overaskelser vil jeg lige dele
med jer.

Min test betod i at lade hovedtr†den og en baggrundstr†d requeste og
release en mutex-agtig "dims" et antal gange, hvor jeg s† skiftede
"dimsen" ud efter behag (rettelse: fantasi og evne), heriblandt to
"dimser", som er extremt hurtige, men bruger data i user space, med
det problemer der deraf f›lger.

Alle dimserne var pakket p‘nt ind i C++ klasser mm.

Her er implementationen af de to extremt hurtige "dimser"
---CUT---
(Watcom-fniller-fnaller gjort mere l‘sbart)
void LockedIncrement(unsigned *p)                -> "lock inc dword ptr [eax]"
void LockedDecrement(unsigned *p)                -> "lock dec dword ptr [eax]"
unsigned LockedExchange(unsigned *p, unsigned v) -> "lock xchg ecx,[eax]"

class FastMutex {
        unsigned toggle;
        unsigned waiters;
        FEventSemaphore try_again;
public:
        FastMutex() : toggle(0), waiters(0), try_again() {}
        void Request();
        void Release();
};

void FastMutex::Request() {
        LockedIncrement(&waiters);
        for(;;) {
                if(LockedExchange(&toggle,1)==0) {
                        LockedDecrement(&waiters);
                        return;
                }
                try_again.Wait();
                try_again.Reset();
        }
}

void FastMutex::Release() {
        toggle=0;
        if(waiters!=0)
                try_again.Post();
}


//----------------------------------------------------------------------------
// A very fast, but unfriendly, mutex

class SpinMutex {
        enum { spin_retries=100 };
        unsigned toggle;
        unsigned waiters;
        FEventSemaphore try_again;
public:
        SpinMutex() : toggle(0), waiters(0), try_again() {}
        void Request();
        void Release();
};

void SpinMutex::Request() {
        for(unsigned spin=0; spin<spin_retries; spin++) {
                if(LockedExchange(&toggle,1)==0)
                        return;
        }
        LockedIncrement(&waiters);
        for(;;) {
                if(LockedExchange(&toggle,1)==0) {
                        LockedDecrement(&waiters);
                        return;
                }
                try_again.Wait();
                try_again.Reset();
        }
}

void SpinMutex::Release() {
        toggle=0;
        if(waiters!=0)
                try_again.Post();
}
---CUT---
Forskellen mellem FastMutex og SpinMutex er, at SpinMutex pr›ver at
tage ejerskab 100 gange (i h†bet om at den nuv‘rende ejer frigiver
den), og hvis det ikke lykkes, g†r den tilbage til FastMutex's strategi.

Her er k›rselstiderne:
OS                    "Dims"          Iterationer Sekunder   Fremregnet
--------------------------------------------------------------------
OS/2 2.11 SMP         OS/2's mutex      5000      1.514      151.4
OS/2 2.11 SMP         fast            500000      1.919        1.919
OS/2 2.11 SMP         spin            500000      0.733        0.733
OS/2 2.11 SMP         OS/2's spinlock 500000      8.930        8.93
OS/2 Warp 3           OS/2's mutex     50000      0.814       81.4
OS/2 Warp 3           fast            500000      0.981        0.981
OS/2 Warp 3           spin            500000      0.937        0.937
NT 3.51               NT's mutex       50000      7.016       70.16
NT 3.51               fast            500000      3.670       36.7        (1)
NT 3.51               spin            500000      0.73         0.73
NT 3.51               NT's crit_sec    50000      6.990       69.90
NT 4.00               NT's mutex      500000     42.86        42.86
NT 4.00               fast            500000      3.50         3.50
NT 4.00               spin            500000      0.73         0.73
NT 4.00               NT's crit_sec    50000      4.061       40.61
OS/2 Warp 4           OS/2's mutex    500000     10.11        10.11
OS/2 Warp 4           fast            500000      0.998        0.998
OS/2 Warp 4           spin            500000      0.89         0.89
Warp adv srv 4 SMP(2) OS/2's mutex    500000     80.820       80.820
Warp adv srv 4 SMP    fast            500000      3.600        3.600
Warp adv srv 4 SMP    spin            500000      0.74         0.74
Warp adv srv 4 SMP    OS/2's spinlock 500000      9.73         9.73       (3)

Noter:
1  Jeg kan huske at jeg k›rte den test et par gange extra for at v‘re sikker,
   fordi tiderne var m‘rkelige. Efter at Henrik Wahlberg gjorde mig opm‘rsom
   p† at noget ikke stemte er jeg kommet i tvivl igen.
2  P† trods af at "OS/2 Warp version 4 Advanced Server SMP" har et 4-tal i sig,
   S† lugter den mest af Warp 3.
3  Spinlock APIet jeg brugte var 16-bit, selvom der i de nyere SMP toolkits
   er erkl‘ret 32-bit API til spinlocks. 32-bit APIet er beklageligvis 50%
   langsommere :-(

Aftestningerne af foretaget p† motherboard med 2 stk. 100MHz Pentiums.
Hvis en test har taget under 5 sekunder, der testen k›rt 10 gange og
tallet ovenover at gennemsnittet af de 10 k›rsler.

Observation 1:OS/2 2.11 SMP's Mutex semaforer er sl›ve.
De er dobbelt s† sl›ve som Warp'ens. Jeg ved ikke hvor hurtige OS/2
2.1's mutex semaforer er, s† det er muligt at mutex semaforerne er
optimeret i Warp'en.

Observation 2: De spinlocks, som findes i OS/2 SMP, er
forholdsvis hurtige p† trods af skift til ring 0 via 16:16 call gates.
Beklageligvis findes spinlocks ikke i single-processor versionerne af
OS/2, og man kan kun eje 1 spinlock ad gangen.

Observation 3: Uanset hvilket OS man bruger er det en god ide at
overveje at bruge noget a'la SpinMutex, hvis man har performanceproblemer.
S† vidt jeg ved, er det ogs† lige hvad IBM har gjort i de nyere versioner
af UICL.

Observation 4: NT's "critical section" er en fis i en hornlygte. Den
er knap m†lbart hurtigere en NT's mutex semafor.


Grunden til at jeg lavede denne test var, at et af mine programmer
k›rte m‘rkbart langsommere under OS/2 SMP end under Warp. Det ser ud
til at det er mutexsemaforerens skyld.