As I understand it, the barrier in that patch ensures that for whichever
thread executes the if(!sqlite3GlobalConfig.mutex.xMutexAlloc codepath)
{...}, the write to pTo->xMutexAlloc will be stored after the rest of the
xMutex* field writes. But there's nothing preventing another thread
*loading* them out of order; e.g. loading an uninitialized
sqlite3GlobalConfig.mutex.xMutexInit into a register prior to loading a now
initialized sqlite3GlobalConfig.mutex.xMutexAlloc (hence skipping the if()
block in sqlite3MutexInit()), which could effectively result in a
sqlite3MutexInit() call with sqlite3GlobalConfig.mutex.xMutexInit
still being null after (for some number of cycles).
https://gist.github.com/vinterstum/ff4bc1ea715cc1d4c5da45864c9de4af should
help I think.
On Tue, Jan 28, 2020 at 4:57 PM Richard Hipp <d...@sqlite.org> wrote:
> On 1/28/20, Oystein Eftevaag <oyste...@google.com> wrote:
> > in sqlite3MutexInit() sqlite3GlobalConfig.mutex.xMutexAlloc
> > can be read as being set on a core, while the rest of the initialization
> > done in sqlite3MutexInit() still is being read as unset.
>
> Doesn't the memory barrier at
> https://www.sqlite.org/src/artifact/bae36f8af32c22ad?ln=247 prevent
> that? Do you have a suggested patch to make it work?
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
