Otheus, I never dealt with reporting on bugzilla, it seems ti me I don't quite qualify and I'm afraid I will post something not pertinent, so if you would agree to do it yourself, here are the results from 2nd version of your 'gettimeofday-based' code, which I re-run 4 times as to get average:

SCO
$ tmx2
575108.94 semop/s (5000000/8694005)
$ tmx2
575215.00 semop/s (5000000/8692402)
$ tmx2
575183.63 semop/s (5000000/8692876)
$ tmx2
559832.49 semop/s (5000000/8931243)

Linux:
$ ./tmx2
129363.77 semop/s (5000000/38650699)
$ ./tmx2
129428.22 semop/s (5000000/38631452)
$ ./tmx2
129601.55 semop/s (5000000/38579786)
$ ./tmx2
129511.76 semop/s (5000000/38606534)


As you see, no difference from the former tests.

Just for my clarification: somehow people who participated in this discussion on unix.com formu as well as on kerneltrap and other places were very concerned with 2 things, that in my perspective are irrelevant to the subject of this thread: time measurement accuracy and involvement of running multiple processes/shells etc that would muddy the results. I would wholeheartedly agree to that IF SCO vs Linux results were comparable. But this is not the case here. SCO is three times faster, no matter we used my method or gettimeofday very accurate method. With all the overhead being roughly similar, I would think we were kind of beating around the bush when we were trying to achieve have accuracy in measurement (which does not hurt, of cource!), but it made the thread bloated.

Again, thanks to Otheus for your suggestions, at this point I the kernel code you pinpoint shows that multi-cpu capability adds a layer of complexity and it does not help the speed. Your and strcmp's (kerneltrap forum) recomendations to upgrade Linux kernel are well taken.
migurus