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
