[Gluster-devel] GlusterD-2.0 - thread safety

[Justin Clift]

Forwarding this, as it's possibly very relevant for the
GlusterD-2.0 stuff.  It looks like the threading behaviour of Go
is very different to other languages (somewhat practical outline
given below).

(Start with the "Normally, in any mainstream language ..." bit)

It's probably worth being aware of sooner rather than later, and
thinking through potential ramifications before we decide to go
down that route. ;)

Regards and best wishes,

Justin Clift
------------


Begin forwarded message:
Date: Thu, 6 Nov 2014 01:10:45 +0100
From: nicolas riesch <nicolas.riesch at gmail.com>
To: General Discussion of SQLite Database <sqlite-users at sqlite.org>
Subject: Re: [sqlite] Is sqlite thread-safety sufficient for use with
"Go" language ?


Pardon me, I will try to reformulate my question more clearly.

My scenario:

  - sqlite is set to Multi-thread mode (SQLITE_THREADSAFE=2), or
    Serialized mode (SQLITE_THREADSAFE=1)
  - I create N logical threads in my "Go" program.
  - Each logical thread creates a database connection, for its
    "exclusive" usage.
    Logical thread LT1 creates connection C1, logical thread LT2 creates
connection C2, etc.
    Logical thread LT1 only makes call to connection C1, never to
connection C2, C3, etc. Same for other threads.

Normally, in any mainstream language (C, PHP, etc), the same OS thread
makes the successive calls to sqlite3_prepare(), sqlite3_step(),
sqlite3_column(), sqlite3_finalize(), etc.
In the loop to retrieve all records in a table, there is no reason to
call sqlite3_step() on a different OS thread each time.

But in Go, it is possible that each call to sqlite3_step() is scheduled
to run on a different OS thread.
Indeed, the execution of a logical Go thread (called a Goroutine) can
switch from one OS thread to another one, without the user being aware
of it, at each function call.

E.g. logical thread LT1 can dispatch function calls on connection C1
like this:
OS thread a --sqlite3_prepare(C1)--
--sqlite3_column(C1)--
OS thread b
--sqlite3_step(C1)--
--sqlite3_column(C1)--
OS thread
c
--sqlite3_step(C1)--                      --sqlite3_finalize(C1)--

For each connection, function calls always occur sequentially, but
possibly on a different OS thread each time.

Logical thread LT2 executes simultaneously, but calling functions only
on connection C2.
Logical thread LT3 executes simultaneously, but calling functions only
on connection C3.
etc...

So, in this scenario, I imagine that with SQLITE_THREADSAFE=1 or
SQLITE_THREADSAFE=2, there should be no problem ?

Is it correct to say that each function of the C API doesn't care on
which OS thread it is run, as long as the sequence of calls is correct ?

I know that in www.sqlite.org/threadsafe.html, it is written that "In
serialized mode, SQLite can be safely used by multiple threads with no
restriction.", but I just wanted to have a confirmation that it really
applies in the particular scenario above.


2014-11-05 23:13 GMT+01:00 Simon Slavin <slavins at bigfraud.org>:

>
> On 5 Nov 2014, at 10:05pm, nicolas riesch <nicolas.riesch at gmail.com>
> wrote:
>
> > Even if the user writes a Go program with only one logical thread,
> > he has no control about which OS thread will process a function
> > call.
> >
> >     This means that EACH SUCCESSIVE function in the sequence above
> > can be processed on a DIFFERENT OS THREAD.
> >
> > It means that to run safely, sqlite source code should not depend
> > in any way on the identity of the threads, which must be fully
> > interchangeable. So, the following conditions should be true. Are
> > these sentences correct
> ?
> >
> > 1) no local-thread-storage is used in sqlite code.
> > 2) thread id (gettid()) are not used.
> > 3) when a function of the API enters a mutex, it leaves it before
> > the function returns.
> >   Between two API function calls, no mutex should be locked (else,
> > it would be impossible to ensure that the mutex is unlocked by the
> > same
> thread
> > that locked it).
> > 4) all file locking information is attached to connections, and not
> > to threads.
>
> Since you don't already refer to it, can I ask that you read this page
>
> <https://www.sqlite.org/threadsafe.html>
>
> and then ask any questions which remain, plus any new ones ?  You
> should probably tell us which threading mode you intend to use based
> on the needs you outline above.
>
> Simon.

_______________________________________________
sqlite-users mailing list
sqlite-users at sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

-- 
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift