Vitali, I don't think the issue is one of threads/parallel processing being evil, it's just that they are more prone to programmer oversight or error, especially on REALLY BIG real-time systems/servers accessing databases.
My career experience has been that the larger and more complicated the software, the more knowledge and skill required of the development staff to produce a high quality product. Considering that possibly as many as 50% of the people I've encountered in my 22 year career in IT were not particularly well-suited for what they were doing, large system size and system complications increase the likelihood of a non-failsafe product. The treatise in this link: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf focuses on threads but the same arguments can be made for all parallel processing. And I think the author's points are at least somewhat valid; the current development paradigms do not provide good mechanisms for ensuring zero-defect code in large, complex systems where a lot has to be known by the developers about all components of the system to ensure correct synchronization, correct serialization of events, the prevention of race conditions, and the elimination of the possibility of deadlocks. To a large degree, the problems with function focused software were solved with object-oriented, data type based, properly implemented class-based software. Maybe it is time for our industry to begin to look for the next technological improvement that will make multi-threaded/parallel processing applications more robust. Lee Crain ___________________________________ -----Original Message----- From: Vitali Lovich [mailto:[EMAIL PROTECTED] Sent: Thursday, October 04, 2007 3:58 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Bug: Database connection closed on different thread I'm confused with your statement about threads. With multi-core multi-cpu machines becoming more prevalent on the desktop, seems to me that multi-threaded apps would provide better performance (obviously for specific problem sets). Also, don't apps that properly separate UI and background work benefit from being multi-threaded (i.e. UI remains responsive despite processing) even on single-cpu machines? Granted, writing correct multi-threaded apps may be more difficult, but I would disagree that they're evil - it just requires a higher level of programmer and better understanding of the architecture. [EMAIL PROTECTED] wrote: > patters <[EMAIL PROTECTED]> wrote: > >> Greetings, >> >> We ran into a bug that's not documented behavior: closing a connection that >> was created in a different thread (where thread A calls sqlite3_open[16], >> "hands off" the connection to thread B, and thread B calls sqlite3_close). >> >> The documentation (http://www.sqlite.org/faq.html#q6) says that any >> functions can be used with a connection as long as it's not being used by >> another thread. With SQLITE_ENABLE_MEMORY_MANAGEMENT defined, >> > > The documentation says that when SQLITE_ENABLE_MEMORY_MANAGEMENT > is defined then all operations against a database connection must > occur in the same thread in which the database connection was > originally opened. > > This constraint exists for all versions of SQLite before and > including 3.4.2. The constraint is removed in version 3.5.0. > > And as is my custom, I must also warn you that your best remedy > is to not use threads in the first place since threads are > evil and programs that use threads are almost always buggy and > slow. If you feel compelled to use threads in spite of this > warning, then upgrading to SQLite version 3.5.0 will probably > work out better for you than trying to use version 3.4.2 or > earlier. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > -------------------------------------------------------------------------- --- > To unsubscribe, send email to [EMAIL PROTECTED] > -------------------------------------------------------------------------- --- > > > -------------------------------------------------------------------------- --- To unsubscribe, send email to [EMAIL PROTECTED] -------------------------------------------------------------------------- --- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
