Hi Marc,
"Marc L. Allen" writes:
> If I understand correctly, the purpose of the overall mutex is to prevent a
> page from being removed underneath a user. If the standard DB locking
> semantics are working properly, I think there is no possibility of a page's
> data from being modified underne
Hi Pavel,
Pavel Ivanov writes:
> > "There are four levels to the shared-cache locking model: transaction
> > level locking, table level locking, cache level locking, and schema
> > level locking. They are described in the following three sub-sections."
>
> This would be a bad way of documentin
AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Multi-Thread Reads to SQLite Database
On 13 Aug 2012, at 3:11pm, Marc L. Allen wrote:
> I wonder if it would be possible to refine the cache locking mechanism.
>
> If I understand the modified DB/Table locking semantics when r
On 13 Aug 2012, at 3:11pm, Marc L. Allen wrote:
> I wonder if it would be possible to refine the cache locking mechanism.
>
> If I understand the modified DB/Table locking semantics when running under a
> shared-cache, it appears that the cache page should be protected against
> readers and w
I wonder if it would be possible to refine the cache locking mechanism.
If I understand the modified DB/Table locking semantics when running under a
shared-cache, it appears that the cache page should be protected against
readers and writers.
Perhaps only the list of pages in the cache need to
> "There are four levels to the shared-cache locking model: transaction
> level locking, table level locking, cache level locking, and schema
> level locking. They are described in the following three sub-sections."
This would be a bad way of documenting this because "cache level
locking" works
Another idea for you:
> In our test, on the other hand, each thread queries its own set of
> rows from the table. So, based on your explanation, here each thread
> should end up with its own set of pages (more or less). However, even
> in this case, I still observe a near sequential performance.
Hi Richard,
Richard Hipp writes:
> In shared-cache mode, SQLite acquires a mutex on the shared cache, thus
> serializing access.
Oh, that's quite a surprise. I would have never said that something
like this is going on just by reading the documentation page on shared
cache:
http://www.sqlite.o
Behalf Of Boris Kolpackov
Sent: Monday, August 13, 2012 8:51 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Multi-Thread Reads to SQLite Database
Hi Richard,
Richard Hipp writes:
> In shared-cache mode, the page cache is shared across threads. That
> means that each thread must acquir
On Mon, Aug 13, 2012 at 8:51 AM, Boris Kolpackov wrote:
>
> Also, your explanation doesn't feel quite satisfactory to me.
>
In shared-cache mode, SQLite acquires a mutex on the shared cache, thus
serializing access.
The mutex is acquired because it is usually needed. You can argue that
there ar
Hi Richard,
Richard Hipp writes:
> In shared-cache mode, the page cache is shared across threads. That means
> that each thread must acquire a mutex on the page cache in order to read
> it. Which means that access to the page cache is serialized.
I just ran our concurrency test in different con
On Fri, Aug 10, 2012 at 12:18 PM, esum wrote:
>
> However, when I ran this same test with SQLITE_OPEN_READWRITE |
> SQLITE_OPEN_SHAREDCACHE for the flags, I get the following [slower]
> results:
>
> Why am I seeing such a high increase in times as I add threads in shared
> cache mode as opposed t
12 matches
Mail list logo