What do the Mutex and Cache sqlite3_open_v2 flags mean?

EDIT: If I could navigate documents I'd be dangerous. http://www.sqlite.org/sharedcache.html

ORIGINAL:

The sqlite3_open_v2 function bears the signature:

int sqlite3_open_v2(
  const char *filename,   /* Database filename (UTF-8) */
  sqlite3 **ppDb,         /* OUT: SQLite db handle */
  int flags,              /* Flags */
  const char *zVfs        /* Name of VFS module to use */
);

The third argument, int flags, supports a number of options, some of which are self-explanatory:

#define SQLITE_OPEN_READONLY         0x00000001  /* Ok for sqlite3_open_v2() */
#define SQLITE_OPEN_READWRITE        0x00000002  /* Ok for sqlite3_open_v2() */
#define SQLITE_OPEN_CREATE           0x00000004  /* Ok for sqlite3_open_v2() */
/* snip */
#define SQLITE_OPEN_NOMUTEX          0x00008000  /* Ok for sqlite3_open_v2() */
#define SQLITE_OPEN_FULLMUTEX        0x00010000  /* Ok for sqlite3_open_v2() */
#define SQLITE_OPEN_SHAREDCACHE      0x00020000  /* Ok for sqlite3_open_v2() */
#define SQLITE_OPEN_PRIVATECACHE     0x00040000  /* Ok for sqlite3_open_v2() */

I'm not having any issues with my database usage (yet), but I'd like to know what the NOMUTEX vs FULLMUTEX and SHAREDCACHE vs PRIVATECACHE options imply. The description from the sqlite.org page I found, for SQLITE_OPEN_NOMUTEX for instance, isn't very helpful.

If the SQLITE_OPEN_NOMUTEX flag is set, then the database connection opens in the multi-thread threading mode as long as the single-thread mode has not been set at compile-time or start-time.

What does the mutex flag do, if simultaneous reads/writes are already guarded against according to the documentation?
Also, what goes in the cache, and if I decide to share it, who am I sharing with and how does that affect their reads/writes?
Is it flushed on close() only?

Any insight at all is appreciated, even a link to a better description would be great.

In short So cumbersome to explain that if you run Single thread you don't have to care else read below:

That is the most cubersome part of SQLIte. If it was rev 1, I will even call that "ill conceived", but as it was incremental evolution with some backward compatibility, I understand the path and mind set followed by the developer. As opposed as what you may feel reading the official documentation: not all combinations work!!!

Also while decision of the mode can be postponed until call to sqlite3_open_v2(,,,) it BETER be chosen once and for all. The good is that you can decide multiple strategy as long as each is on different db file.

That said:

SQLITE_OPEN_NOMUTEX does compile (or active on sqlite3_open_v2), the usage of SQLite without internal mutex. Still safe to be use SQLite multithread BUT in my experience work only safely with individual connection open in each thread. Do NOT try to share a connection between Thread with this mode.

SQLITE_OPEN_FULLMUTEX SQLite at runtime does create appropriate mutex to lock some atomic operation. I use it when I share connection between thread. (In fact I ALWAYS use FULLMUTEX) If you want to see where search sqlite3.c for sqlite3_mutex_enter(db->mutex); And know that when NOMUTEX the db->mutex == NULL and no lock occurs

Use SQLITE_OPEN_FULLMUTEX always. Mutex handling are very fast now, no real impact on performance. Disk/parsing are fare more onerous in cpu and it is unclear what the benefit of NOMUTEX unless you are ready to reverse engineer code of sqlite3.c

However I successfully experiment NOMUTEX in Multithread using mutiple connection (one open_v2 in each thread) but using this you also need to worry about decision on CACHE (I use SQLITE_OPEN_PRIVATECACHE, not all combination work, also changing the mode once db have and especially the caching systeme once already been open is really looking for trouble) Choose a MUTEX+CACHE+sync+journal strategy before first open and stick with it.

See also this very good article about https://dev.yorhel.nl/doc/sqlaccess