3 ms·
> Mutex lock/unlock 25ns That looks suspiciously cheap to me, 1/4th the cost of accessing main memory? I tend to think of mutex ops as quite expensive cons
by Freaky 17y ago
> Mutex lock/unlock 25ns
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.
- alain94040 17y agoLocking 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.
- neilc 17y agohttp://www.feyrer.de/NetBSD/gmcgarry/ 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).
- Freaky 17y ago> 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.