Spinlocks are almost always dumb, real dumb.
Spinlocks came from the VAX/VMS kernel where they were used when the kernel needed to communicate with a device and knew the response would be available in less time than it would take up to set up for and process an interrupt. That's a clear win (Cutler was no a dummy). In almost any other situation, they are a loss for a very easy to understand reason: By spinning, one thread/process is hogging the resource that the other thread/process needs to release the lock.
My Falcon MySQL storage engine was in a DBT2 performance horse race with the InnoDB storage engine. InnoDB used spinlocks. Falcon had nicely passed InnoDB's starting performance when Google replaced the InnoDB spinlocks with my user mode read/write locks, which gave InnoDB a substantial boost in performance. It took InnoDB (then owned by Oracle) six months to negotiate a license from Google, but the writing was on the wall.
InnoDB, incidentally, implemented MVCC by putting pointers in their lock table pointing into their transaction log, which allowed them to fetch old version but at some cost. When the lock table was full, well, InnoDB stopped working, but that couldn't happen in DBT2.
--
Support the ongoing development of Firebird! Consider donating to the Firebird Foundation and help ensure its future. Every contribution makes a difference. Learn more and donate here:
https://www.firebirdsql.org/donate
---
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/firebird-devel/a3e7a2e3-b1d5-4f1b-b3b3-c738337ec6d0n%40googlegroups.com.