> I meant the mutex that is a member of the BtShared struct > (BtShared.mutex). Grabbed by the call to sqlite3VdbeMutexEnterArray() > at the top of sqlite3VdbeExec() and not released until that function > returns.
Okay, now I see that and I don't like it at all. Of course it doesn't eliminate ability to make 2 write transactions on different tables simultaneously but this ability now narrows significantly to the cases when transaction consists of more than one update and thus more than one call to sqlite3_step(). Do you know the reasons why it was made that way? What operations are made with shared cache that cannot be parallelized and require such a wide exclusive lock (especially in case of read-only transactions but cases of writing to different tables are questionable too)? Pavel On Wed, Nov 18, 2009 at 11:55 PM, Dan Kennedy <danielk1...@gmail.com> wrote: > > On Nov 18, 2009, at 10:03 PM, Pavel Ivanov wrote: > >> I don't know what Dan meant by his words but AFAIK there's no mutex >> making exclusive grab of shared cache by sqlite3_step() call. There is >> only mutex making sqlite3_step() execution exclusive for connection >> object. > > I meant the mutex that is a member of the BtShared struct > (BtShared.mutex). Grabbed by the call to sqlite3VdbeMutexEnterArray() > at the top of sqlite3VdbeExec() and not released until that function > returns. > > Pavel is right, technically it's not grabbed by sqlite3_step(). But > 99% of the time spent in sqlite3_step() will be spent in a single call > to sqlite3VdbeExec(), so the effect is similar. > > Dan. > > > > >> Pavel >> >> On Wed, Nov 18, 2009 at 8:40 AM, presta <harc...@gmail.com> wrote: >>> >>> I'm confused according to Dan Kennedy : >>> >>> "Each shared-cache has its own mutex. The mutex is held for the >>> duration >>> of each sqlite3_step() call. So the way you're defining it here, you >>> can't have "real" concurrency when using shared-cache mode in any >>> case. " >>> >>> So, it's a little bit "antagonist" to say "with shared cache they >>> will be >>> parallelized pretty effectively in the same file too" >>> >>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/Asynchronous-I-O-and-shared-cache-tp26402983p26407922.html >>> Sent from the SQLite mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
