We find that synchronizing access to database writes using a mutex works
well. You could think of implementing read and write locks using the
thread primitives and achieve a better result.
If you do poll to resolve busy checks a spinlock is certainly a bad
idea. When we use that approach we will yield the thread after each busy.
[EMAIL PROTECTED] wrote:
Hi,
I am having a scenario where I have one reader/writer and many writer threads.
All writers are pretty basic (single INSERT INTO; some sort of a logging info
what a thread has done).
I believe I will receive many BUSY return codes and I don't like these
spinlock-like retries. The problem I am having with this design is that I would
like to complete the thread ASAP, so that I don't have many threads idling and
consuming resources of my embedded system.
I was thinking to either:
a. Use mutex/semaphore before writting to the database or
b. Have a (thread safe) list of INSERT INTO strings that every writer thread
populates and the main reader/writer thread later executes.
Is this a good approach? Does anyone have a better design? I don't want to use
other database, because I think Sqlite is great for an embedded system that I
am using.
___________________________________________________________________________
Najhitrejši brezplačni klicni dostop :: Varno in zanesljivo po internetu
Obiščite http://www.dialup386.com/
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
