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* th
On 1/28/20, Oystein Eftevaag 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
Hi folks,
Data races in sqlite3_initialize was previously reported in
https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg94225.html
and
a fix landed, however while investigating internal TSan reports of this, as
far as we can tell the issue is still present (on non-x86 platforms
3 matches
Mail list logo
