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
> >> [email protected]
> >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >>
> >
> >
> >
>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
Alexander Batyrshin aka bash
bash = Biomechanica Artificial Sabotage Humanoid
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
