On 2016/04/06 6:03 AM, sanhua.zh wrote: > Recently, I am reading the source code of SQLite. > I found that on OS level, SQLite use file lock to solve multi-processes > problem and use VFS to solve multi-threads problem. But all of them might > failed with racing and SQLite will return a SQLITE_BUSY result code to make > it sleep-and-retry. > > > I get confused of this code. Why SQLite use lock-and-wait? For example, in > the unixLock, we can use F_SETLKW instead of F_SETLK, so that code will > return immediatly when file unlocked. We have not need to sleep-and-retry, > which may waste our running time. > > > So I think it might be a kind oftrick, but I don?t why SQLite do so. I > already find out the www.sqlite.org, but it tells nothing about this. Does > anybody know why SQLite design it so?
SQLite is platform independent - i.e. it works on all systems and has to make do with what is available everywhere. F_SETLKW is not available on all platforms and can't be a standard way for SQLite to interface. You can however make your own VFS for SQLite that implements it on Unix systems, if you like. This is quite easy. Does F_SETLKW have a timeout? what must SQLite do if the file still doesn't become available after a long time? How would this be better than the current way? You probably know this already, but the lock-checking mechanism is quite efficient, and a locked file gets re-checked (if a timeout is specified) very quick, then successively longer and longer intervals until the timeout expires. I doubt you will see a great increase in lock-situation performance using the file-lock wait cycle - but if you do make that VFS, perhaps we could do some testing of the hypothesis. Cheers, Ryan
