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
