ok, so you posted under subject "semaphore access speed" but the numbers were not a really crude benchmark for said semaphore access speed, but a simplification of your complete application that uses shell scripts. you could have said so, that would have had you wondering less why everyone talked about semaphore access speed not shell scripts... this is the first time you tell people you are not actually interested in what they thought you asked.
under many systems there is only one syscall entry in the kernel, but of course there are many syscalls. so the syscall entry behaves like a http://en.wikipedia.org/wiki/Multiplexer that multiplexes the syscalls -- combining all syscalls into a single entry point. there is a hidden function argument to determine which syscall you actually meant (register AH under DOS, register %eax under linux, ...). as you can see in the strace output, linux uses this to implement two different syscalls semctl and semget, while truss shows that SCO implements a single syscall for semaphores semsys and uses _another_ function argument for selecting which one: semsys(1, ...) or semsys(0, ...). this is what was linked to and it has nothing to do with your question so I wondered why it was linked.
the linux you benchmarked is "Fedora 2.6.9", what you actually mean is some RHEL with linux (kernel) 2.6.9? but all you want is your application not being slow? and people posted results for 2.6.24 that seem to behave normally? why don't you draw the conclusion and just install some modern distro yourself and re-test that? to find out, if this is version specific or a general problem. if you don't want a full install, you can simply boot a live CD; these days you can even install software inside a booted live CD ('write' to the CD) that remains until reboot, so you can install a C compiler or other packages if they are missing but needed for your benchmark. only disk access times are much worse on the CD, I don't know if your shell script is affected by this.
subject
ok, so you posted under subject "semaphore access speed" but the numbers were not a really crude benchmark for said semaphore access speed, but a simplification of your complete application that uses shell scripts. you could have said so, that would have had you wondering less why everyone talked about semaphore access speed not shell scripts... this is the first time you tell people you are not actually interested in what they thought you asked.
under many systems there is only one syscall entry in the kernel, but of course there are many syscalls. so the syscall entry behaves like a http://en.wikipedia.org/wiki/Multiplexer that multiplexes the syscalls -- combining all syscalls into a single entry point. there is a hidden function argument to determine which syscall you actually meant (register AH under DOS, register %eax under linux, ...). as you can see in the strace output, linux uses this to implement two different syscalls semctl and semget, while truss shows that SCO implements a single syscall for semaphores semsys and uses _another_ function argument for selecting which one: semsys(1, ...) or semsys(0, ...). this is what was linked to and it has nothing to do with your question so I wondered why it was linked.
the linux you benchmarked is "Fedora 2.6.9", what you actually mean is some RHEL with linux (kernel) 2.6.9? but all you want is your application not being slow? and people posted results for 2.6.24 that seem to behave normally? why don't you draw the conclusion and just install some modern distro yourself and re-test that? to find out, if this is version specific or a general problem. if you don't want a full install, you can simply boot a live CD; these days you can even install software inside a booted live CD ('write' to the CD) that remains until reboot, so you can install a C compiler or other packages if they are missing but needed for your benchmark. only disk access times are much worse on the CD, I don't know if your shell script is affected by this.