Emerson Clarke wrote:
If i have a linked list, i can use it across threads if i want to,
provided that i synchronise operations in such a way that the list
does not get corrupted.
And of course you also have to know about memory barriers and compiler
re-ordering. That is highly dependent on the libraries and/or compiler
you are using, as well as underlying hardware implementation. Most of
the time, developers just get lucky.
http://en.wikipedia.org/wiki/Memory_barrier
Likewise for most other data structures and libraries.
Arguably that is by luck and not design! Look at the effort that to go
in an add _r suffixed versions of several functions in the standard
libraries. And many GUI libraries have long had a restriction that you
can only use them in one thread.
Sqlite does not follow these rules, as something created in one thread
does not work in another thread regardless of synchronisation and it
is out of my control.
SQLite's design was not "luck". The design expects you to create unique
sqlite3 objects in each thread. Effort and thought was put into that!
http://www.sqlite.org/cvstrac/wiki?p=MultiThreading
It was loosened a bit in 3.3.x:
http://www.sqlite.org/faq.html#q8
What isn't allowed is multiple statements executing at the same time in
multiple threads against the same sqlite3* db object. In order to
support that, SQLite would have to have extensive code protecting the
various internal data structures as well as ensuring concurrency.
This is not a situation that i would expect anyone to purposefully
design becuase it makes multithreaded programming difficult,
The purposeful design is that you make sqlite3 objects per thread. That
way there is absolutely no danger of corruption or other bad issues.
Roger
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
