Mivel nem úgy tűnik, hogy kövesse az utasításokat, nem is várom el, hogy értékeljék a következő kódot. Ha mégis, és az eredményeket is széles körben váratlan, kérjük, jegyezze fel ide.

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <time.h>
#define NSEMS   2
main(int argc, char *argv[])
{
    time_t start,stop;
    long int i;
    int sid;
    key_t key;
    ushort vals[NSEMS] = { 0, 0 };

    key = ftok("/tmp",99);
    start=time(NULL);
    for (i = 0; i < 5000000; i++) {
      if ((sid = semget(key, NSEMS, IPC_CREAT | 0777)) == -1) {
          perror("Can Not Get Semaphore ID");
      }
      if (semctl(sid, NSEMS, GETALL, vals) == -1) {
          perror("Can Not Get Semaphore Values");
      }
    }
    stop=time(NULL);
    printf("%.2f semop/s [%i,%i]\n", (double)i/(stop-start), vals[0], vals[1]);
}

Csak a hangsúlyt, az eredményei közé tartozik az általános kiindulási számos folyamatokat, és mindegyik, a nyomtatás egy sor szöveget a pufferelt blokk eszközt, és kilépek a folyamatot. Szűk bármely ezekhez sokkal valószínűbb, hogy magyarázza az eredményeket, mint a dolog kívánt tesztet.

Én össze, és futtassa a tesztet loop code posted by Otheus.

Xeon / SCO eredmények: 555555,56 semop / s [0,0]
Xeon / Linux eredmények: 128205,13 semop / s [0,0]

Nem férnek hozzá PIII dobozban van, hanem az eredmények azonos (arányosan), mint amit én láttam az én vizsgálat azt hiszem, nem döntő jelentőségű, hogy nem PIII eredmények itt.

Ami a felsővezeték által említett Era - Tisztában vagyok azzal, hogy, mivel ez nagyban hasonlít a helyzet értékeléséhez, hogy én vagyok, így a teszt érvényes, és nem felügyelet.

Szóval, ez bárkinek bármilyen ötlete, mi az akadálya lehet? vagy ha látod? Nagyon köszönjük türelmét velem, és a kitartás abban, hogy a mélyére.

Belépés egy szemaforhoz - feltételezve, hogy nincs deadlock - a közvetlen memória-hozzáférést, üzemeltetése, hozzátéve, egy egész oldalt vagy többszöröseként feldolgozni memória van fölött. Ez magában foglalja egy drága hívás: brk (), ha nem emlékszik már ott.

Ez attól függ, hogy milyen

size mycode

gcc -p -g -o otherus otheus.c
otheus.c
grpof otheus

PS hívás utimes (struct tms *) és a tényleges idő, plusz granularitása CLK_TCK van, általában így jobban, mint a time ().

gettimeofday lehet használni, hogy fal még pontos időt is. utimes () visszatér clock_t fal idő.

Jim, utimes () ezt nem teszi, mit gondolsz, igen. Gettimeofday több helyes, de akkor a kód egy kicsit bonyolultabb. Mikroszekundum különbségek nem járna az eltérő teljesítményt is látni.

Jim,
Soha nem próbáltam a profil előtt, úgyhogy futott néhány probléma:
$ Gcc-pg-o tstloop tstloop.c
$ Tstloop
128205,13 semop / s [0,0]
$ Gprof tstloop
gprof: gmon.out fájl hiányzik call-graph adatok

Any ideas?

Ami használata idő vs gettimeofday (ami valójában én használata) teljesen irreleváns, én próbálok, hogy hányszor egy második rendszer képes létrehozni azt a folyamatot, amelynek csak olvasni szemaforhoz.

Köszönöm.