I am not understand this example. First of all second process can't promote exclusive lock from reserved. It should use intermediate pending lock. And secondary why first process can't just drop read lock and then invoke busy handler?
In this case any write to database that already has process On Thu, Apr 24, 2008 at 6:01 PM, Simon Davies <[EMAIL PROTECTED]> wrote: > Alexander, > > From http://www.sqlite.org/c3ref/busy_handler.html > > "The presence of a busy handler does not guarantee that it will be > invoked when there is lock contention. If SQLite determines that > invoking the busy handler could result in a deadlock, it will go ahead > and return SQLITE_BUSY or SQLITE_IOERR_BLOCKED instead of invoking the > busy handler. Consider a scenario where one process is holding a read > lock that it is trying to promote to a reserved lock and a second > process is holding a reserved lock that it is trying to promote to an > exclusive lock. The first process cannot proceed because it is blocked > by the second and the second process cannot proceed because it is > blocked by the first. If both processes invoke the busy handlers, > neither will make any progress. Therefore, SQLite returns SQLITE_BUSY > for the first process, hoping that this will induce the first process > to release its read lock and allow the second process to proceed" > > Rgds, > Simon > > 2008/4/24 Alexander Batyrshin <[EMAIL PROTECTED]>: > > > > Oh... Nope, I am not using any thread-mechanism. > > I am using simple processes (via fork). So synchronization should be > > task for SQLite library. > > > > But right now I am confused, because my processes do not blocks on > > sqlite3_exec. They immediately report BUSY_TIMEOUT, without awaiting > > for time set by sqlite3_busy_timeout. > > > > > > > > On Thu, Apr 24, 2008 at 4:29 PM, John Stanton <[EMAIL PROTECTED]> wrote: > > > If it is one process I would assign a mutex to the resource (Sqlite) and > > > wait on it to get access to the resource. When the Sqlite operation is > > > complete release the mutex and the next thread will have exclusive > > > access to it. > > > > > > If you use pthreads you can use read and write locks to get concurrency > > > on reads. > > > > > > To my mind syncing on a mutex is better and simpler than polling the > > > resource using SQLITE_BUSY. > > > > > > > > > > > > Alexander Batyrshin wrote: > > > > So, you advice me, to implement synchronization inside my process by > my self? > > > > > > > > On Thu, Apr 24, 2008 at 3:40 PM, John Stanton <[EMAIL PROTECTED]> > wrote: > > > >> You have a single shared resource, Sqlite, and you have to > synchronize > > > >> access. You can use the internal locking in Sqlite and use polling > or > > > >> wait on a mutex or semaphore. > > > >> > > > >> > > > >> Alexander Batyrshin wrote: > > > >> > Hello All, > > > >> > > > > >> > I am observing situation, that my concurrency process does not > have > > > >> > access to SQLite database with equal probability. > > > >> > > > > >> > Here is example. I have N process that do work like this: > > > >> > > > > >> > while (1) { > > > >> > do_some_work(); // takes ~ 30 sec > > > >> > save_work_result_to_sqlite(); // takes ~ 1 sec > > > >> > } > > > >> > > > > >> > So, as you can see, these N process has concurrency access to > SQLite database. > > > >> > In theory in worst case, save_work_result_to_sqlite() should NOT > wait > > > >> > for access to database longer than N * 1 sec. > > > >> > But in practice, some process blocks on save_work_to_sqlite() more > > > >> > than N*2 sec and dies on my SQLITE_BUSY asserts :/ > > > >> > > > > >> > So, I am wondering, is there any ideas how to avoid this? > > > >> > > > > >> > > > >> _______________________________________________ > > > >> sqlite-users mailing list > > > >> sqlite-users@sqlite.org > > > >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > -- > > Alexander Batyrshin aka bash > > bash = Biomechanica Artificial Sabotage Humanoid > > _______________________________________________ > > > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Alexander Batyrshin aka bash bash = Biomechanica Artificial Sabotage Humanoid _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
