That looks suspiciously cheap to me, 1/4th the cost of accessing main memory? I tend to think of mutex ops as quite expensive considering they involve things like memory barriers.
Locking a semaphore should be the same cost as accessing a (potentially cached) memory location. If you own the mutex and are unlocking it, then 25 ns sounds fine. If you are grabbing the lock from another cpu or core, then it will definitely be way more than that.
There would be some cache snooping to invalidate the other cpu's lock and gets your local version dirty.
http://www.feyrer.de/NetBSD/gmcgarry/ suggests that the cost to acquire an uncontested mutex on NetBSD in 2005 was ~37 nsec, so ~25 nsec doesn't seem too unreasonable (although strangely it was more expensive on FreeBSD).
> although strangely it was more expensive on FreeBSD
I think mutex ops in 5.3 depended on syscalls or so. I distinctly remember a commit reducing mutex overheads by moving more of it into userspace, somewhat like futex I guess.
That looks suspiciously cheap to me, 1/4th the cost of accessing main memory? I tend to think of mutex ops as quite expensive considering they involve things like memory barriers.