-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Gregurich wrote: > Given the industry is going multicore and 16-core macintoshes for your > grand-mother are just a few years away, I recommend you rethink your > position on the use of threading.
Threading is the worst solution to many cpu/core and large memory. Having the same memory addressed (which is what threading does) across multiple concurrently executing cpus/cores causes cache thrashing, memory contention, frequent use of memory barriers for synchronization (which also slows things down) and as memory becomes attached to individual cpus leads to access being over hypertransport/csi. Far better is using multiple processes which don't have those issues. A good example application to study is Google Chrome which uses multiple processes prolifically - each tab is a separate process, as well as the various plugins, languages etc. Each process can be appropriately locked down using the principle of least privilege. If you use threads then typically they all have permission to do anything the process could do. (Also the multi-process approach is way easier to test, record/replay and is more deterministic) Erlang is also worth studying. It only has single threaded processes (although the processes are lighter weight than operating system processes). > NSOperation is a major part of that effort. If the "single encapsulated task" doesn't go around concurrently touching bits of memory then it could be shunted to a separate process anyway. The danger from threads is not the threads themselves, but the concurrency. It is virtually impossible to prove that a threaded process does the concurrency correctly under all circumstances. If you eliminate the concurrency then you can use multiple processes, and can usually even make it scale over multiple machines! Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn5Q9MACgkQmOOfHg372QSS/QCfSje/tyX0hmidHyubVKqrXlHt Sq0AoKEbmcwx/fmAFtcVeMjbcUgN8dr3 =8lUQ -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
