On Tue, May 18, 2010 at 12:50:20PM -0500, Black, Michael (IS) scratched on the wall: > Rats on the interprocess locks.
More to the point, database connection mutexes are just for the database connection. Even the same process with more than one database connection might fight with each other, and the mutex locks are going to do nothing to prevent that. All concurrency locking is currently done through the file locks, so that's what you have to work with. > I was still talking about sleeping for spinning the BUSY return -- Sleeping and spinning are two fundamentally different ideas. You have to pick one, and you only get to choose on an MP/MC machine. > but just doing it as fast as possible without using much CPU Fast burns CPU. If you spin, you never let go of the CPU. If you sleep, you usually stay asleep. Most OSes won't really give you extremely short sleep times and, even if they could, the wake-up and context switch is an expensive thing, especially if you just hit the lock again and go back to sleep. > instead of picking 10ms which seeem too long to me when the > transactions should take sub-millisecond times. Only if you're not sync'ing the disks. On most systems, the simplest write transaction is going to take at least 15ms. http://sqlite.org/faq.html#q19 -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
